Vídeos sobre IPv6 do RIPE/NCC

Recentemente o RIPE/NCC publicou (e continua publicando) uma série de vídeos de entrevistas com engenheiros de rede sobre a implementação do IPv6 em suas redes. Aproveitem!

Mais informações no canal do RIPE/NCC no Youtube.

Eventos: GTER/GTS e ysts

Neste mês de junho, São Paulo vai abrigar dois eventos "de peso" na área de redes e segurança: a reunião conjunta do GTER/GTS (Grupo de Trabalho de Engenharia e Operação de Redes/Grupo de Trabalho em Segurança) que acontece nos dias 19/06 (GTER) e 20/06 (GTS) e a conferência de segurança "mais badalada do Brasil" - o You Sh0t the Sherrif 3.0 - que acontece no dia 22 de junho. 

A reunião do GTER/GTS é organizada pelo CGI.br e o NIC.br e tem como objetivo fomentar a discussão de aspectos relevantes para a operação e segurança da Internet brasileira. O evento é gratuito e acontece nos dias 19 e 20 de junho no Hotel Blue Tree Towers Morumbi com um programa de apresentações que inclui palestras sobre ASN de 4 bytes, BGP, VoIP, crimes cibernéticos e outros temas de interesse da comunidade de engenheiros de rede e segurança. Mais informações no site oficial. 

Já a edição 3.0 do ysts - organizada pelo criadores do podcast de segurança da informação I Sh0t the Sheriff - trás como novidade treinamentos em formato de mini-curso em dias separados do evento principal. A agenda completa do evento está disponível aqui. Mais informações também no site oficial.

Cisco Reverse Telnet

Em localidades remotas com poucos equipamentos (um roteador e um switch, por exemplo) e quando não há um servidor de console disponível, pode-se utilizar a porta auxiliar de um roteador Cisco para conectar-se a console de outro equipamento. Isto é comumente chamado de Reverse Telnet.

Para começar é necessário um cabo do tipo rolled - aquele mesmo azul claro que se acumula aos montes no seu depósito e que uma ponta do cabo está na ordem inversa da outra ponta (veja
figura). O cabo azul claro da Cisco RJ-45/DB-9 também funciona neste caso.


Conecte o cabo console na interface auxiliar do equipamento principal e depois na console do outro equipamento. Depois é necessário fazer a seguinte configuração na interface auxiliar (line aux 0).

line aux 0
 modem InOut
 transport preferred telnet
 transport input all
 transport output telnet
 stopbits 1

Também é necessário que o seu roteador Cisco possua uma interface Loopback configurada para que você possa executar o comando telnet para esta interface.

interface loopback 0
 ip address 10.1.1.1 255.255.255.255

Em seguida, deve-se verificar qual é o número atribuido a sua porta auxiliar. Para isso entre com o comando show line.

Router#show line
 Tty Line Typ     Tx/Rx    A Modem  Roty AccO AccI  Uses  Noise Overruns  Int
   0    0 CTY              -    -      -    -    -     0      0    0/0      -
   1    1 AUX   9600/9600  - inout     -    -    -     1      0    1/1      -
*194  194 VTY              -    -      -    -    -     3      0    0/0      -
 195  195 VTY              -    -      -    -    -     1      0    0/0      -
 196  196 VTY              -    -      -    -    -     0      0    0/0      -
 197  197 VTY              -    -      -    -    -     0      0    0/0      -
 198  198 VTY              -    -      -    -    -     0      0    0/0      -

As duas primeiras colunas mostram o número atribuído a interface auxiliar. Agora basta executar o comando telnet endereço 2000+line. O último parâmetro (porta) deverá ser o número da linha somado com o número 2000 - para este exemplo ficará 2001.

Router#telnet 10.1.1.1 2001
Trying 1.0.0.1, 2001 ... Open

login:

And that's all folks!

Mais informações:

• Cisco IOS Documentation: Establishing a Reverse Telnet Session to a Modem
  

Guideline de segurança - Cisco

Durante a configuração de equipamentos de rede, normalmente temos dúvidas (ou pelo menos todos deveriam ter) do tipo "Será essa a melhor maneira para configurar isto de maneira segura?".

A Cisco possui um guideline com as melhores práticas para configuração, design e implementação de redes de forma segura. Eles atualizaram o documento a pouco tempo.

Está disponível aqui. A página de apresentação do SAFE, nome dado pela Cisco para estes guidelines, é essa.

Lembrando que, apesar das informações serem voltadas para equipamentos Cisco, as idéias podem ser aplicadas para arquiteturas baseadas em outros tipos de equipamento, adaptando, claro, as configurações.

Dica: Internetworkpro Wiki

Ainda em fase de construção, o Internetworkpro Wiki, que como o próprio nome já adianta, é um wiki que pretende reunir artigos técnicos sobre redes, equipamentos e configurações. Por enquanto a maioria das informações existentes é sobre os equipamentos Cisco - mas se você estiver disposto a ajudar, pode escrever sobre Juniper ou Extreme...

O destaque é para as páginas dos roteadores e switches que apresentam um bom resumo de cada plataforma. A página de informações sobre os switches Cisco Catalyst 6500 apresenta um excelente material para uma consulta rápida. É interessante destacar também os diversos exemplos de configuração já disponíveis neste wiki.

Every move you make...

Eu sempre imaginei que instalar e manter um software de gerenciamento e backup de configuração de equipamentos de rede fosse uma grande idéia. Não só para conseguir restaurar um equipamento queimado de uma forma mais rápida - já que o backup, pelo menos, existe - mas também para fazer o acompanhamento das mudanças - afinal de contas, estamos na era da Gerência de Mudanças, não?

Bom, isto foi o que aconteceu com o Nick, um leitor do ISC Diary, e que o pessoal o SANS ISC relatou tão bem. O roteador foi comprometido - com usuário padrão com senha fácil -, e logo o atacante criou um túnel para a sua origem, alterou alguns parâmetros para garantir que a porta estaria aberta da próxima vez e tudo mais. O syslog e o IDS não se manifestaram, afinal de contas, a senha era válida e o acesso era permitido... O atacante só não contava com o Rancid. Assim que o Rancid fez o backup da configuração e detectou a alteração, um e-mail foi enviado para o administrador do sistema e em pouco tempo tudo estava resolvido.

Achei interessante relatar este exemplo aqui, já que o post-tutorial que fiz há algum tempo atrás sobre o Rancid aqui neste blog é disparado o post menos visto de todos os tempos! O que me faz pensar que todos já tem suas soluções de backup e gerenciamento de configuração funcionando a todo vapor ou não temos nenhum leitor mesmo :-). Particularmente eu ficaria com a segunda opção... Você sabe qual é o software usado na sua empresa para gerenciamento e backup de configuração? Você tem uma dica? Deixe-a aí nos comentarios.

Mais informações:

• Página oficial do Rancid.
• Como instalar e configurar o Rancid passo-a-passo.
• "Watch your Internet routers!" - ISC Diary de 30/março/2009.
  

Você está preparado?

"Você está preparado?". É assim que começa a mensagem que circulou hoje na lista LACNOG (lista mantida pelo LACNIC). Esta mensagem, enviada pelo Roque Gagliano, ressalta uma importante questão sobre o suporte do ASN de 32 bits nas mais diversas plataformas e fabricantes. Assunto que já foi discutido por aqui em outubro do ano passado. Naquela época, algumas versões oficiais ainda não suportavam ASN de 32 bits.

O link enviado hoje pelo Roque remete a uma página que contém um bom resumo para verificar como está o suporte a ASN 32 bits hoje, além de muitas outras informações sobre qual é o padrão adotado para a notação do ASN de 32 bits e o calendário de alocação de ASN adotado pelos RIR. Para quem acredita em saci, caipora e cuca (como eu) também pode conferir como está a alocação de ASN (16 bits) no relatório produzido pelo Geoff Huston. A imagem abaixo (retirada deste relatório) mostra a progressão das alocações de ASN de 16 bits até março de 2009 e ainda a projeção linear e exponencial para o futuro.... não muito distante.

Mais informações em:

• The 16-bits AS number report (potaroo.net)
• Software support for 32-bits ASN (wiki)
  

Cancelando com CTRL+C no Cisco

Sempre tive problemas no meu Ubuntu, utilizando o Terminal, para cancelar um traceroute ou um ping quando conectado em um equipamento Cisco. Mas, meus problemas acabaram. E compartilho com vocês do blog. Graças a um comentário na lista da Nanog descobri que, utilizando o comando escape-character 3 dentro dos line vty e do line con, você pode utilizar simplesmente CTRL+C para cancelar o comando.

Portanto, em modo de configuração:

Router(config)#line vty 0 15
Router(config-line)#escape-character 3
Router(config)#line con 0
Router(config-line)#escape-character 3

Um roteador, dois provedores e alguma redundância

De tempos em tempos surge em alguma lista ou forum de discussão a questão de como ter redundância entre dois provedores de forma automática no meu escritório? E essa foi exatamente a questão que foi feita no forum do blog Cisco Certified. É claro que existem soluções proprietárias (o Radware Linkproof, por exemplo) ou open-source para a solução deste problema, mas a solução que vou explicar aqui é toda baseada em um único roteador Cisco recebendo dois links de provedores diferentes (leia-se: com endereçamento válido diferente).

O cenário que iremos tratar neste post é o seguinte:

Neste cenário, o roteador Router está conectado ao ISP 1 e ao ISP 2 através de links ponto-a-ponto e o endereçamento válido que o cliente deverá usar é o mesmo do link. Na rede interna do cliente não existe nenhum servidor (pelo menos para este exemplo). Só existem conexões do escritório (redes 192.168.0.0/24 e 172.16.0.0/24) para a Internet. Neste exemplo também estou considerando que a rede 192.168.0.0/24 irá utilizar o ISP 2 e a rede 172.16.0.0/24 o ISP 1 (devido à política interna, uma rede tem prioridade sobre a outra, etc). Estas redes podem ou não estar diretamente conectadas no roteador Router.

É claro que colocar uma rota default apontando para um ou outro provedor (ISP) não será a nossa solução e, para este caso, quando não podemos utilizar um protocolo de roteamento dinâmico, vamos utilizar duas features da Cisco: o Cisco IP SLA (que já foi tratado neste post) e o Policy-Based Routing (que também já foi tratado neste outro post).

O primeiro passo é configurar uma monitoração com o IP SLA e começar a fazer o tracking desta monitoração. Para isso utilizaremos o Object Tracking.

ip sla monitor 1
 type echo protocol ipicmpecho 10.1.1.2
 frequency 5
ip sla monitor schedule 1 start-time now life forever

ip sla monitor 2
 type echo protocol ipicmpecho 10.1.2.2
 frequency 5
ip sla monitor schedule 2 start-time now life forever

track 123 rtr 1 reachability
track 124 rtr 2 reachability

Para verificar que o tracking está funcionando, utilize o comando show track.

Router#show track
Track 123
  Response Time Reporter 1 reachability
  Reachability is Up
    1 change, last change 00:00:05
  Latest operation return code: OK
  Latest RTT (millisecs) 168
Track 124
  Response Time Reporter 2 reachability
  Reachability is Up
    1 change, last change 00:00:04
  Latest operation return code: OK
  Latest RTT (millisecs) 124

Como estamos preocupados com o tempo de convergência da rede na ocasião de uma falha, configurei o intervalo de testes do IP SLA para 5 segundos. Agora iremos utilizar o tracking que configuramos no passo anterior em um route-map que verificará se o default gateway está respondendo ou não, para então utilizar somente aquele que estiver respondendo.

access-list 11 permit host 172.16.0.1
access-list 12 permit host 192.168.0.1

route-map in-out-link-1 permit 10
 match ip address 11
 set ip next-hop verify-availability 10.1.1.2 10 track 123
 set ip next-hop verify-availability 10.1.2.2 20 track 124

route-map in-out-link-1 permit 20
 match ip address 12
 set ip next-hop verify-availability 10.1.2.2 10 track 124
 set ip next-hop verify-availability 10.1.1.2 20 track 123

Como podemos observar (pelo menos em nosso teste) o host 172.16.0.1 utilizará o ISP 1 (next-hop 10.1.1.2) preferencialmente e o host 192.168.0.1 utilizará o outro ISP. Agora podemos verificar como está o nosso route-map.

Router#show route-map in-out-link-1
route-map in-out-link-1, permit, sequence 10
  Match clauses:
    ip address (access-lists): 11 
  Set clauses:
    ip next-hop verify-availability 10.1.1.2 10 track 123  [up]
    ip next-hop verify-availability 10.1.2.2 20 track 124  [up]
  Policy routing matches: 0 packets, 0 bytes
route-map in-out-link-1, permit, sequence 20
  Match clauses:
    ip address (access-lists): 12 
  Set clauses:
    ip next-hop verify-availability 10.1.2.2 10 track 124  [up]
    ip next-hop verify-availability 10.1.1.2 20 track 123  [up]
  Policy routing matches: 0 packets, 0 bytes

O último passo é configurar o NAT nas interfaces utilizando um route-map para identificar qual é a interface que está sendo utilizada como saída. Dessa forma, quando um determinado pacote for utilizar o link do ISP 1 para acessar a Internet, o NAT irá traduzir para o endereço da interface correspondente (dado que estamos utilizando interface overload na configuração do NAT).

interface fa0/0
 ip nat inside
 ! devemos aplicar o route-map in-out-link-1 na interface conectada na rede
 ! interna para fazer com que o roteador não utilize a tabela de rotas padrão. 
 ip policy route-map in-out-link-1

int atm1/0.1
 ip nat outside

interface atm2/0.1
 ip nat outside

route-map nat-1 permit 10
 match interface ATM1/0.1
!
route-map nat-2 permit 10
 match interface ATM2/0.1
!
ip nat  inside source route-map nat-1 interface atm 1/0.1
ip nat  inside source route-map nat-2 interface atm 2/0.1

Neste momento, podemos fazer a primeira verificação. Como exemplo, estou utilizando um roteador com endereço IP 192.168.0.1 e 172.16.0.1 para fazer os testes.

Host#ping 1.1.1.1 source lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 172.16.0.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/295/760 ms

Host#ping 1.1.1.1 source lo1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.0.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 96/187/304 ms

Este host está conectado na interface fastethernet0/0 do roteador Router. Podemos verificar também que a tabela de NAT está mostrando as traduções para os dois links separadamente.

Router#show ip nat translations
Pro Inside global      Inside local       Outside local      Outside global
icmp 10.1.1.1:116      172.16.0.1:116     1.1.1.1:116        1.1.1.1:116
icmp 10.1.2.1:117      192.168.0.1:117    1.1.1.1:117        1.1.1.1:117

Observe que a primeira linha de traduções mostra a tradução para o endereço 10.1.1.1 (que é o endereço do ISP 1 e a segunda linha mostra a tradução para o endereço do ISP 2: 10.1.2.1. Vamos agora simular a falha do ISP 2 e ver o que acontece com a tabela de traduções e os pings.

Router#show track
Track 123
  Response Time Reporter 1 reachability
  Reachability is Up
    1 change, last change 00:02:45
  Latest operation return code: OK
  Latest RTT (millisecs) 79
  Tracked by:
    ROUTE-MAP 0
Track 124
  Response Time Reporter 2 reachability
  Reachability is Down
    2 changes, last change 00:00:00
  Latest operation return code: Timeout
  Tracked by:
    ROUTE-MAP 0

Router#show route-map in-out-link-1
route-map in-out-link-1, permit, sequence 10
  Match clauses:
    ip address (access-lists): 11 
  Set clauses:
    ip next-hop verify-availability 10.1.1.2 10 track 123  [up]
    ip next-hop verify-availability 10.1.2.2 20 track 124  [down]
  Policy routing matches: 0 packets, 0 bytes
route-map in-out-link-1, permit, sequence 20
  Match clauses:
    ip address (access-lists): 12 
  Set clauses:
    ip next-hop verify-availability 10.1.2.2 10 track 124  [down]
    ip next-hop verify-availability 10.1.1.2 20 track 123  [up]
  Policy routing matches: 0 packets, 0 bytes

Router#show ip nat translations
Pro Inside global      Inside local       Outside local      Outside global
icmp 10.1.1.1:119      172.16.0.1:119     32.1.1.1:119       32.1.1.1:119
icmp 10.1.1.1:118      192.168.0.1:118    32.1.1.1:118       32.1.1.1:118

Aproximadamente cinco segundos após desligar o link para o ISP 2, podemos observar que o tracking não está mais funcionando para o endereço 10.1.2.2 - assim como o nosso route-map -, e a tabela de NAT mostra que agora estamos traduzindo todos os endereços para 10.1.1.1 (que é o endereço do ISP 1).

Lembre-se sempre que este é um exemplo e que para ser aplicado em um ambiente real devem ser feitos alguns ajustes.

Mais informações em:

• Using Object Tracking with Cisco Policy-based Routing.
  

Atualizar Horário de Verão - Juniper M7i 9.1 ou maior

Estava com dificuldades para configurar o horário de verão em um Juniper M7i com JunOS acima de 9.1. Conectei no shell e vi que existia o zic e o zdump. Pensei: se a base é BSD e tenho essas duas ferramentas, por que não fazer igual no próprio FreeBSD?

Tentei e funcionou. E, não é solução de contorno. Achei depois de ter feito um documento na Knowledge Base da Juniper que corrobora a solução.

Entre na shell do Juniper após conectado:

>start shell

Entre no modo superusuário:

#su -
#vi ZONA.zic

Dentro do arquivo, para o caso do horário de verão 2008/2009 (que agora é fixo e, portanto, você pode fazer para todos os anos seguindo as regras), coloque:

Rule Brazil 2008 only - Oct 19 00:00 1 S
Rule Brazil 2009 only - Feb 15 00:00 0 -

Zone ZONA -3:00 Brazil BR%sT

O nome ZONA é o que aparecerá depois na CLI para seleção do seu horário de verão personalizado. Coloque o nome que preferir.

Como referência, indico o site da RNP que sempre coloca o modo de fazer esse tipo de atualização nos sistemas operacionais mais comuns.

Após salva o arquivo, saia e, de volta ao shell em modo root, execute:

#/usr/libexec/ui/compile-tz ZONA.zic

Saia do modo shell e volte para a CLI. Lá, informe ao Juniper que você quer usar a base personalizada de time-zone, e não a padrão:

>set system use-imported-time-zones

Agora, configure seu timezone, escolhendo a zona ZONA:

>set system time-zone ZONA

Salve as configurações e confira com um "show system uptime" se tudo está certo.

Se você tem acesso ao KB da Juniper, clique aqui e acesse o documento que mostra quase isso, que você só vê mastigado aqui no Nexthop.

Perigo! Certificados SSL que utilizam o MD5 podem ser forjados

O pessoal que acompanha assuntos de segurança deve ter lido a respeito do ataque demonstrado por Alexander Sotirov na 25th Chaos Communication Congress, onde ele mostrou a fragilidade do algoritimo de hashes criptográficos MD5 em aplicações PKI, utilizando um cluster formado por 200 Playstation 3.

A vulnerabilidade permite que uma pessoa mal intencionada possa criar uma Rogue Certification Authority e enganar o browser. Certamente isso será muito utilizado para ataques de phishing/pharming sofisticados, combinando com ataques de DNS, ou seja, a imaginação não tem limite para essa vulnerabilidade.

Muitas pessoas não técnicas se bastam do CADEADINHO do browser para se sentirem seguras. Já pessoas com maior conhecimento poderão clicar no cadeado e, mesmo assim, serem enganadas, pois o certificado estaria validado por uma Rogue CA.

As CAs afetadas (que possuem certificados assinados em MD5) terão que trocar esses certificados para seus clientes e isso dará muito trabalho. Essa mudança já deverá ser feita para SHA-2 ou SHA-3, já que SHA-1 também pode ser vulnerável para alguns ataques.


Para as pessoas que utilizam Firefox existem duas extensões que podem auxiliá-lo a detectar se o site HTTPS que você está acessando usa certificados que utilizam MD5:

* SSL BlackList
* Perspectives

Para quem gosta do framework Metasploit, foi disponibilizado recentemente um módulo que pode varrer endereçamentos internos e identificar se existem certificados que precisam ser trocados.