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.
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
interface loopback 0
ip address 10.1.1.1 255.255.255.255
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 -
Router#telnet 10.1.1.1 2001
Trying 1.0.0.1, 2001 ... Open
login:
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.
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...
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:
"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:
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
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
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
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
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
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
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
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
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
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
#su -
#vi ZONA.zic
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
#/usr/libexec/ui/compile-tz ZONA.zic
>set system use-imported-time-zones
>set system time-zone ZONA
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.
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.
