quarta-feira, 17 de julho de 2013

Gerando IPs aleatórios

Pessoal,

Depois de vários anos sem nenhum post no blog resolvi voltar a ativa e publicar algumas dicas que, espero, sejam úteis para alguém.

Esta semana precisei executar uma varredura de portas TCP utilizando a ferramenta Nmap numa subrede muito grande para a qual não havia tempo hábil para varrer todos os IPs. Tive então que optar por trabalhar com amostragem e a escolha aleatória de endereços IP seria muito útil.

No entanto havia um problema: o Nmap não tem uma opção para escolher aleatoriamente um número finito de IPs dentro de um critério de uma subrede específica (o que ele gera com a opção -iR é um IP a partir de todo o endereçamento IP disponível na Internet). Ou seja, mãos a obra!

Aí desenvolvi um script para atender a minha necessidade baseado num artigo que vi no blog do Chad Bibler intitulado Generating a Random, Valid IP Address in Subnet in Python (http://dregsoft.com/blog/?p=24). Meu script randomip.py ficou assim:

#!/usr/bin/env python
import socket
import struct
import random
import math
import sys

def get_max_ips( netmask_length, random_ips ):
    # define maximum number of IP addresses to be generated
    netmask_ips = int( math.pow( 2, 32-netmask_length ) )
    if ( netmask_ips < random_ips ):
        winner = int( math.pow( 2, 32-netmask_length ) )
    else:
        winner = random_ips
    return winner

def get_random_ip_in_subnet( ip, netmask_length ):
    # thanks to Chad Bibler, http://dregsoft.com/blog/?p=24
    # change the IP address into its bytes so we can add a number to it
    n = socket.inet_aton( ip )
    ip_bytes = struct.unpack( '!i', n )[0]
    # we use the netmask_length to get a range of numbers we can add to the IP address
    max_to_add = int( math.pow( 2, 32-netmask_length ) )
    to_add = random.randrange( 0, max_to_add )
    ip_bytes += to_add
    # pack it back up
    and_back = struct.pack( '!i', ip_bytes )
    new_ip = socket.inet_ntoa( and_back )
    return new_ip

if ( len(sys.argv) != 4 ):
    print "Command syntax: "
    print "   python randomip.py   <# of random IPs from subnet>"
    print ""
    print "   example: python randomip.py 192.168.0.0 20 100"
else:
    iplist={}
    max_ips=get_max_ips(int(sys.argv[2]),int(sys.argv[3]))
    for x in range(0, max_ips):
        ip=get_random_ip_in_subnet( sys.argv[1], int(sys.argv[2]))
        while(iplist.has_key(ip)):
            ip=get_random_ip_in_subnet( sys.argv[1], int(sys.argv[2]))
        iplist[ip]=1
        print ip

Na prática o meu a minha varredura TCP para escolher 1000 endereços IP dentro da subrede 172.16.0.0/12 ficou assim:

python randomip.py 172.16.0.0 12 1000 | nmap -v -n --open -sS -iL - -oA nmap_out

Podem utilizar o script livremente e sugiro para quem quiser se aventurar no desenvolvimento do script três melhorias:
  1. Fazer com que o script em randomip.py aceite um arquivo de entrada com vários blocos IP (para o caso de subredes descontínuas)
  2. Fazer com que o script aceite como parâmetro um ASN (autonomous system). Neste caso ele sortearia os IP baseados neste ASN ou lista de ASNs (os blocos IP deste ASN poderiam ser recuperados a partir de site da ripe.net ou de alguma informação de BGP externa).
  3. Fazer com que o script aceite como parâmetro a sigla de um país (por exemplo sortear IPs que sejam somente da China). A lista poderia ser recuperada de sites como ipdeny.com 
Abraços e boa sorte a todos!

sábado, 15 de maio de 2010

Ajude a Medir a Qualidade da Internet no Brasil

O projeto SIMET já existe há algum tempo como uma iniciativa do Comitê Gestor da Internet no Brasil e se propõe a medir a qualidade da Internet no Brasil. O projeto depende da participação da comunidade de usuários da Internet (técnicos ou leigos) para medir - em todas as regiões do Brasil - a banda disponível, perda de pacotes e até mesmo jitter nos diversos provedores espalhados pelo Brasil. Este é um tipo de projeto que ajuda os provedores a melhorar suas redes, o que obviamente ajuda os usuários da Internet brasileira.


Para participar (aproveite, é indolor e grátis!!) basta clicar no link para o projeto ou acessar o endereço http://www.ceptro.br/Simet.

sexta-feira, 19 de junho de 2009

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.

quinta-feira, 4 de junho de 2009

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.

quarta-feira, 3 de junho de 2009

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:

segunda-feira, 18 de maio de 2009

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.

sábado, 25 de abril de 2009

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.

segunda-feira, 30 de março de 2009

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:

segunda-feira, 23 de março de 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:

segunda-feira, 23 de fevereiro de 2009

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

sexta-feira, 20 de fevereiro de 2009

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:

terça-feira, 17 de fevereiro de 2009

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.

quarta-feira, 7 de janeiro de 2009

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.

terça-feira, 23 de dezembro de 2008

Verificar Interface Ótica

Esta é a primeira dica que recebemos via e-mail (!!!). É um simples comando que nem aquele que tudo indexa (google) conseguiu encontrar. A dica foi enviada pelo Rodrigo Stival Lopes (obrigado Rodrigo!!). A referência mais próxima que conseguimos encontrar é o "show hw-module subslot transceiver" no Cisco IOS Interface and Hardware Component Command Reference. Vejam um exemplo abaixo:

Switch# show hw-module all transceiver 001 status
The Transceiver in slot 0 subslot 0 port 1 is enabled.
Module temperature = +44.390 C
Transceiver Tx supply voltage = 3300.4 uVolts
Transceiver Tx bias current = 25344 uAmps
Transceiver Tx power = -1 dBm
Transceiver Rx optical power = -7 dBm

Como podemos ver através da documentação da Cisco, o show hw-module permite verificar informações do hardware e o estado operacional (potência, tipo, conector, etc) de interfaces óticas SFP (small form-factor pluggable).

Mais informações:

quinta-feira, 20 de novembro de 2008

Cisco IP SLA

Conhecida antes da versão 12.4T como RTR (Response Time Report) e SAA (Service Assurance Agent), a ferramenta de monitoração Cisco IP SLA (Service Level Agent) é utilizada para fazer monitoração ativa de tempo de resposta via ICMP (ou utilizando outras aplicações como HTTP e DNS), jitter (inclusive jitter unidirecional), perda de pacotes, etc. diretamente em um roteador Cisco, ou seja, sem depender de um outro software ou servidor para fazer a colheta destas informações. Apesar das informações estarem disponíveis no roteador, é também interessante utilizar alguma ferramenta para gerar um gráfico, como o MRTG ou Cacti, para deixar o seu chefe ainda mais feliz! :-)

Configurando o IP SLA

Vamos ver um exemplo de configuração para medir o tempo de resposta entre dois pontos utilizando a ferramenta para medir jitter do IP SLA. Entenda dois pontos como um circuit ponto-a-ponto ou dois pontos quaisquer na Internet. Veja a configuração:

! criamos a monitoração 100 para o endereço IP 10.10.10.1
!
ip sla 100
icmp-jitter 10.10.10.1 source-ip 192.168.1.1 num-packets 20
frequency 300
!
! então é necessário ativar a monitoração recém criada
!
ip sla schedule 100 start-time now life forever

Depois de criarmos a monitoração e ativá-la, podemos verificar se está funcionando e como está o nosso tempo de resposta e perda de pacotes com o comando show ip sla statistics 100.

Router#sh ip sla statistics 100

Round Trip Time (RTT) for Index 100
Type of operation: icmpJitter
Latest RTT: 230 milliseconds
Latest operation start time: 13:04:36.499 BRST Wed Nov 26 2008
Latest operation return code: OK
RTT Values:
Number Of RTT: 13 RTT Min/Avg/Max: 325/354/413
Latency one-way time:
Number of Latency one-way Samples: 0
Source to Destination Latency one way Min/Avg/Max: 0/0/0
Destination to Source Latency one way Min/Avg/Max: 0/0/0
Jitter Time:
Number of SD Jitter Samples: 9
Number of DS Jitter Samples: 9
Source to Destination Jitter Min/Avg/Max: 1/5/17
Destination to Source Jitter Min/Avg/Max: 0/25/71
Packet Late Arrival: 0
Out Of Sequence: 0
Source to Destination: 0 Destination to Source 0
In both Directions: 0
Packet Skipped: 0 Packet Unprocessed: 7
Packet Loss: 0
Loss Period Length Min/Max: 0/0
Number of successes: 1
Number of failures: 0
Operation time to live: Forever

As informações que queremos observar estão destacadas em azul.

Gerando os Gráficos

Para continuar este exemplo, vamos gerar um gráfico das informações de RTT (round-trip time) máximo e mínimo. Para isso, vamos utilizar o MRTG e os OIDs:
  • rttMonLatestIcmpJitterRTTMin.XXX ou 1.3.6.1.4.1.9.9.42.1.5.4.1.4.XXX para medir o RTT mínimo da instância XXX (no nosso caso a instância 100).
  • rttMonLatestIcmpJitterRTTMax.XXX ou 1.3.6.1.4.1.9.9.42.1.5.4.1.5.XXX para medir o RTT máximo da instância XXX.
A configuração do MRTG utilizada foi:

# IP SLA 100
Target[rtt_mon_100]:1.3.6.1.4.1.9.9.42.1.5.4.1.4.100&1.3.6.1.4.1.9.9.42.1.5.4.1.5.100:community@192.168.1.1:
MaxBytes[rtt_mon_100]: 350
AbsMax[rtt_mon_100]: 2000
YLegend[rtt_mon_100]: Round Trip Time
ShortLegend[rtt_mon_100]: ms
LegendI[rtt_mon_100]: min rtt (ms):
LegendO[rtt_mon_100]: max rtt (ms):
Legend1[rtt_mon_100]: min rtt (ms)
Legend2[rtt_mon_100]: max rtt (ms)
Title[rtt_mon_100]: Tempo de Resposta - IP SLA 100


Para a monitoração que configuramos anteriormente, podemos obter um gráfico que nos mostrará o tempo de resposta mínimo (em verde) e o máximo (em azul). Deste gráfico podemos ter uma idéia de como está o jitter para um determinado circuito ou caminho.
Com esta simples monitoração é possível observar a variação do tempo de resposta com o passar do tempo (veja figura 1 no período entre 18:00 e 22:00 horas) ou ainda verificar que um determinado caminho está congestionado - com alterações no tempo de resposta, principalmente durante certos períodos (veja figura 2).

Figura 1

Figura 2

Para mais informações:

quarta-feira, 12 de novembro de 2008

Monitoração de prefixos BGP na Internet

O Problema

Depois dos diversos problemas de sequestro de prefixos BGP na Internet - como o famoso caso YouTube versus Pakistan Telecom - as ferramentas de monitoração de prefixos BGP, gratuitas ou pagas, ganharam mais visibilidade entre os administradores de rede ao redor do mundo. E nesta última terça-feira, 11 de novembro às 2:00 horas GMT, uma destas ferramentas começou a disparar inúmeros alertas alegando que o AS16735 havia sequestrado uma grande quantidade de prefixos (mais de 50% dos prefixos existentes na Internet). Veja um exemplo do alerta gerado pelo BGPmon:

You Receive this email because you are subscribed to BGPmon.net.
For more details about these updates please visit:
http://bgpmon.net/showupdates.php

====================
Possible Prefix Hijack (Code: 11)
1 number of peer(s) detected this updates for your prefix
10.10.80.0/20:
Update details: 2008-11-11 02:24 (UTC)
10.10.80.0/20
Announced by: AS16735 (Companhia de Telecomunicacoes do
Brasil Central)
Transit AS: 27664 (CTBC Multimídia)
ASpath: 27664 16735
=====================
Como os administradores que receberam estes alertas não conseguiram alcançar o AS16735, logo assumiram que o sequestro realmente tinha acontecido, já que ao verificar a situação dos prefixos sequestrados no RIS (ferramenta do RIPE) ou no looking glass do PTT-Metro, também constataram que o AS-path (27664 16735 ou ainda 22548 16735) não estava correto.

Os Fatos

O primeiro fato interessante é que tanto o AS27664 e quanto o AS22548 são clientes de trânsito do AS16735 e os dois primeiros (AS27664 e o AS22548) estão alimentando com a tabela BGP completa o projeto RIS do RIPE no PTT-Metro (rrc15). Isso significa que tanto para o RIS quanto para o BGPmon (que utiliza as informações do RIS para monitorar e gerar os alertas) ínumeros prefixos da tabela BGP passaram a ser anunciados pelo AS16735 - o que comumente é conhecido como leaking (ou vazamento) da tabela BGP. Já que o AS16735 não possui autoridade administrativa sobre estes prefixos, podemos supor então que houve um re-anúncio da tabela BGP, este último causado por algum problema interno ao AS16735.

Esse sequestro de prefixos, no entanto, não foi percebido em nenhum outro ponto da Internet - ficando restrito ao AS16735 e seus clientes, como é o caso do AS27664 e AS22548 - graças aos filtros existentes na maioria dos sistemas autônomos ou grandes operadoras de telecomunicações. Ainda de acordo com as análises do BGPmon e da Renesys, este problema durou aproximadamente 5 minutos. Mas, mesmo depois deste período, muitos outros sistemas autônomos continuaram não alcançando a rede do AS16735, pois grande parte do AS16735 não estava acessível em razão de outros problemas. E este último fato aumentou consideravelmente o burburinho sobre este problema.

As Lições Aprendidas

A primeira grande lição é não confiar somente em uma fonte de informação, como foi o caso de muita gente. Para ter certeza do problema, verifique a informação nos mais diversos servidores de looking glass espalhados pelo mundo. Como exemplo, o primeiro looking glass que eu verifiquei naquela madrugada, sequer soube da existência do AS16735 no caminho destes inúmeros prefixos... Mesmo assim, esse tipo de problema não deve ser subestimado.

É interessante também utilizar vários sistemas de monitoração e verificação dos prefixos na tabela BGP da Internet, desde que estes sistemas sejam alimentados por fontes de informação diferentes (esse não foi o caso do RIS, BGPmon ou do Looking Glass do PTT-Metro). Alguns exemplos de ferramentas disponíveis para verificação são: Internet Alert Registry, WatchMY.net, BGPmon e PHAS.

Por último (e já não tão relacionado com o que acabei de descrever) fica a dica de uma ferramenta (ainda beta) para visualização mais amigável das informações colhidas pelo projeto RIS e pode ser acessada da página principal do projeto, entrando com a informação de número de AS ou prefixo próximo ao canto superior direito.


Tela da ferramenta de visualização do RIS/RIPE.

Atualizado em 13/Nov/2008:

Ontem a noite, algumas horas depois de terminar este post, Danny McPherson publicou no blog da Arbor Networks uma análise muito semelhante a exposta acima, no entanto, ele acrecentou um ponto que eu também gostaria de destacar aqui:

Toda esta confusão só poderá ser evitada com a utilização de uma solução segura para roteamento entre-domínios (ou sistemas autônomos). E este padrão está em fase de desenvolvimento dentro do IETF, mais especificamente através do grupo SIDR (Secure Inter-Domain Routing). Queria destacar também a apresentação do Ricardo Patara (do LACNIC) na última reunião do GTER sobre este tema. Vale a pena dar uma olhada!

Mais informações em:

terça-feira, 11 de novembro de 2008

Adicionando as buscas da Cisco no seu Browser

Agora podemos fazer buscas na página web da Cisco diretamente na barra de endereços do seu browser. Por enquanto disponível apenas para Firefox e Internet Explorer. As buscas possíveis são:

Ferramentas (conteúdo fechado, é necessário possuir uma conta CCO para acessar)

Buscas

Mais informações na página da Cisco: http://www.cisco.com/web/tsweb/searchplugins/plugin_homepage.html#

segunda-feira, 3 de novembro de 2008

O que mudou ?

Este post, de certa forma, completa dois outros antigos posts publicados aqui: o primeiro deles sobre o Replace e o Rollback da configuração de roteadores Cisco e o segundo post sobre a ferramenta de backup de configuração open-source chamada Rancid. Desde a versão 12.3(4)T do Cisco IOS é possível utilizar o próprio CLI para saber o que mudou no seu roteador da seguinte forma:

Router#show archive config differences

Vejamos um exemplo:

Router#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#int fa0/0
Router(config-if)#ip address 172.16.0.1 255.255.255.0
Router(config-if)#^Z
Router#show archive config differences nvram:startup-config system:running-config
Contextual Config Diffs:
interface FastEthernet0/0
+ip address 172.16.0.1 255.255.255.0
+ip route 192.168.2.0 255.255.255.0 172.16.1.10
interface FastEthernet0/0
-ip address 192.168.0.1 255.255.255.0
Hum. Alguém já havia alterado a rota 192.168.2.0 deste roteador (e não tinha salvado a configuração!!!), além da configuração que acabamos de alterar (endereço IP da interface Fa0/0). Este é somente um exemplo de uma configuração extremamente simples, mas podemos imaginar a ajuda que podemos ter em configurações mais complexas e em grandes mudanças.

Outro ponto importante desta feature é o fato de conseguirmos comparar a configuração atual (running-config) com uma configuração armazenada em um servidor TFTP. Se combinarmos as configurações armazenadas no Rancid com a opção de comparar a configuração direto no roteador, temos uma poderosa ferramenta em mãos.

Router#show archive config differences tftp://10.1.1.1/Router.bkp system:running-config
(...)

Mais informações em:

Aumentando a velocidade do show running-config

Muitas vezes nos deparamos com um equipamento que possui muitas linhas de configuração e, ao executar um comando de show running-config, demora muito para que o comando retorne a configuração atual além do que gera uma carga adicional de processamento ao equipamento.

A partir das versões 12.2(25)S, 12.2(27)SBC e 12.3(7)T é possível otimizar esta operação criando um cache da configuração atual, o que reduz em até 90% o tempo de execução de um show running-config (efetuei testes em laboratório e o tempo diminui de 30 segundos para 3 segundos).

Router(config)# parser config cache interface

Após a aplicação deste comando é preciso executar um primeiro show run para que seja criado o cache. Todos os show running posteriores devem ter um ganho de performance (obs: será consumido uma parcela da memória do equipamento para este cache).

Link:
http://www.cisco.com/en/US/docs/ios/12_3t/12_3t7/feature/guide/gtinvgen.html

segunda-feira, 27 de outubro de 2008

Usando o Ping (Cisco)

O Ping é certamente um dos programas mais utilizados para testar a conectividade de rede. Nos roteadores Cisco é "o" programa para testar não somente se existe conectividade, mas também para nos garantir que não há erros ou problemas (leia-se: perda de pacotes, etc). Tudo começa com o ping e deve terminar com várias exclamações consecutivas (ou pontos consecutivos, no pior caso).

router#ping 10.10.10.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/8/20 ms
Se quisermos melhorar um pouco o nosso teste, podemos utilizar um ping estendido:
router#ping
Protocol [ip]:
Target IP address: 10.10.10.1
Repeat count [5]: 10
Datagram size [100]: 1000
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 10, 1000-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds:
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 12/24/68 ms
Ou ainda, de forma mais rápida e resumida, o mesmo comando:
router#ping 10.10.10.1 repeat 10 size 1000

Type escape sequence to abort.
Sending 10, 1000-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds:
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 12/16/32 ms
Quando estamos testando conexões seriais (a.k.a. links ponto-a-ponto) é importante fazer o teste com vários padrões de dados (ou data pattern) e é aí que podemos melhorar ainda mais nossos testes, pois somente o teste com vários padrões poderá nos revelar erros mais raros, mas que também podem perturbar a vida de um administrador de rede. Os padrões mais comuns são:
  • 0x0000 ou 0xFFFF: para verificar se o circuito pode lidar com "all-zeros" (ou "all-ones"). Pode indicar problemas de codificação da operadora (bz8s/ami).
  • 0x4040, 0x1010, 0x8080, 0xaaaa: zeros e uns alternados utilizados para indicar problemas com circuitos mal provisionados.
Lembrando que na opção padrão o comando ping dispara pacotes echo-request com o padrão de dados 0xabcd. Para alterar o padrão, basta utilizar a seguinte opção:
router#ping 10.10.10.1 repeat 10 size 1000 data 4040

Type escape sequence to abort.
Sending 10, 1000-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds:
Packet has data pattern 0x4040
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 12/16/36 ms
Mais informações em: