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 RegistryWatchMY.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:

segunda-feira, 20 de outubro de 2008

Dica: tcpdump

Nada como matar dois coelhos com uma paulada só. Para aqueles que gostam de resumos de comandos mais usados, dicas, resumo,... essa é uma ótima dica sobre o tcpdump e muitas outras coisas... como EIGRP, BGP, IPSec, etc. As (já famosas) cheat sheets do blog Packetlife.net são excelentes (fica aqui também a dica do blog que, assim como as cheat sheets, é excelente).

Ainda sobre o tcpdump, essa cheat sheet do Packetlife.net completa a coleção daquelas que já foram indicadas em um post sobre tcpdump aqui, nele também existe algumas dicas de como utilizar o tcpdump.

domingo, 19 de outubro de 2008

Inscrições abertas para o GTER/GTS

Acontece nos próximos dias 7 e 8 de novembro em São Paulo a 26a. reunião do GTER (Grupo de Trabalho de Engenharia e Operação de Redes) em conjunto  com a 12a. reunião do GTS (Grupo de Trabalho em Segurança). Os dois grupos são coordenados por renomados profissionais da área de redes e segurança com o apoio do CGI.br (Comitê Gestor da Internet no Brasil). As duas reuniões têm como objetivo promover a discussão de assuntos relevantes para operação e administração da Internet no Brasil. O programa completo com as apresentações está disponível aqui.


Faça sua inscrição E participe !

quinta-feira, 16 de outubro de 2008

YSTS 2.0


Estão abertas as inscrições para o YSTS 2.0 (You Shot the Sherif 2.0). Promovido e totalmente organizado pela equipe do podcast I Shot the Sherif (este que já foi comentado aqui outras vezes e está na nossa lista de links favoritos aí do lado direito) esse é um evento sobre segurança da informação que pretende reunir palestras técnicas e não-tão-técnicas para agradar a todos os gostos em um ambiente diferente, descontraído e único. Marcam presença nesta edição dois keynotes "de peso": David "h1kari" Hulton e Emmanuel Goldstein. Além de palestras com os mais renomados especialistas de segurança do Brasil.

terça-feira, 14 de outubro de 2008

Dica: Material sobre PCI DSS

Eduardo Camargo Neves publicou no último mês de agosto um excelente artigo sobre o padrão de segurança da informação criado pelas principais empresas operadoras de cartões de crédito (PCI Security Standards Council) chamado PCI DSS (Payment Card Industry Data Security Standard). Com a crescente utilização dos cartões de crédito como forma principal para realização de transasões eletrônicas, e consequentemente o aumento do volume financeiro total destas transações, aumenta também a quantidade de fraudes eletrônicas (ou criminosos utilizando-se do meio eletrônico para desviar recursos). A preocupação das empresas também vêm ganhando (muito) espaço no sentido da segurança e por isso foi criado o PCI DSS, na tentativa de inibir o roubo de informações pessoais que posteriormente serão utilizadas nestas fraudes.

Ainda segundo o Eduardo:"(...) Os controles estabelecidos pelo PCI Council tem a vantagem de serem simples, eficazes dentro do escopo ao qual se propõe a abordar e altamente escalonáveis. Este artigo mostra em uma visão geral, como estes padrões nasceram, quais controles são esperados e como a sua empresa pode se alinhar para um processo de certificação. (...)." [veja aqui o artigo completo]

Mais informações em:

segunda-feira, 13 de outubro de 2008

NANOG 44 Webcast


Desde ontem até o próximo dia 15 de outubro (quarta-feira) acontece em Los Angeles a NANOG 44. Como é de costume, grande parte das apresentações será transmitida via streaming (ao vivo) a partir das 9:30 PDT (13:30 BRT). A agenda e os arquivos das apresentações estão disponíveis aqui.

sexta-feira, 10 de outubro de 2008

Dica: CCIE SP Dynamips Mini Cenários

Este post é uma forma de agradecer o Antonio Soares (CCIE No. 18473) por ter criado uma coleção completa de mini cenários (todos no Dynamips) para a maioria do conteúdo da prova do CCIE Service Provider, organizado tudo isso por assunto e publicado aqui for free!

quinta-feira, 9 de outubro de 2008

Cisco Flexible Netflow

Lançado com a versão 12.4(9)T do IOS, o Cisco Flexible Netflow é uma atualização ao já largamente utilizado Cisco Netflow. Esta atualização permite configurações mais detalhadas e a possibilidade de fazer o cache de informações para fins específicos, como por exemplo, análises de segurança ou billing. Neste último mês de setembro, a Cisco publicou um white-paper completo descrevendo a tecnologia e como ela pode ser utilizada nas redes convergentes mais atuais :-). Consulte a documentação oficial do Flexible Netflow para mais informações sobre configuração e funcionamento desta tecnologia.

quarta-feira, 8 de outubro de 2008

Cisco Policy-Based Routing

Policy-Based Routing (ou PBR) é uma técnica utilizada para forçar um determinado fluxo de pacotes por um caminho diferente daquele que o fluxo normalmente seguiria se estivesse sendo roteado pela tabela de roteamento padrão de um roteador. Por exemplo, assim que um fluxo chega até uma das interfaces de um roteador, este roteador deve consultar a tabela de roteamento para determinar para qual interface os pacotes deverão ser comutados e isso é o comportamento padrão de um roteador IP.

Quando utilizamos uma PBR, estamos alterando este comportamento e fazendo com que os pacotes que cheguem até uma interface, sejam comutados para uma interface diferente daquela apontada pela tabela de roteamento; e isso é configurado nos roteadores Cisco através do comando route-map e da cláusula set ip next-hop. Como exemplo, vejamos um route-map aplicado a interface Ethernet0. Todos os pacotes que chegarem a esta interface serão comutados para uma interface na rede 10.1.1.1, de forma que os pacotes possam ser encaminhados para o endereço 10.1.1.1.

route-map ENVIA_PARA_10.1.1.1
set ip next-hop 10.1.1.1

interface ethernet0
ip policy route-map ENVIA_PARA_10.1.1.1
No entanto, existem duas formas de utilizar o comando set ip next-hop e um comportamento padrão que deve ser muito bem observado durante a sua utilização:

O comando set ip next-hop irá verificar a existência do próximo salto (next-hop) válido e...
- Se o próximo salto existe na tabela de roteamento, então o pacote é encaminhado para o próximo salto especificado.
- Se o próximo salto não existe na tabela de roteamento, então o roteador utiliza da tabela de roteamento padrão para encaminhar os pacotes.

O comando set ip default next-hop também irá verificar a tabela de roteamento e...
- Se o destino existir na tabela de roteamento, encaminha o pacote utilizando as informações da tabela de roteamento.
- Se o destino não existir na tabela de roteamento, encaminha o pacote de acordo com o next-hop especificado no comando.

Para mais detalhes sobre esse comportamento e exemplos de configuração, consulte este documento da Cisco. É possivel também combinar as características de roteamento baseado em política (PBR) com as opções de tracking e IP SLA para verificar se o next-hop é alcançável ANTES de aplicar a PBR. Mais detalhes sobre a utilização desta solução aqui.

segunda-feira, 6 de outubro de 2008

BGP AS com 4 Bytes

Tradicionalmente o número de sistema autônomo (aka AS) possui 2 bytes (ASN16 ou 2 octetos), permitindo assim que estes sistemas autônomos utilizem teoricamente qualquer número no intervalo de 1 até 65536. O número de sistema autônomo identifica uma rede (ou um conjunto de redes) que possui uma mesma política de roteamento e está sob administração de um conjunto comum de pessoas (por exemplo, um provedor de serviços Internet). Este número é utilizado pelo protocolo BGP, mais precisamente no atributo AS_PATH, que determina a que distância encontra-se uma rede, medindo essa distância pelo número de sistemas autônomos que deve-se atravessar para alcançar a rede em questão.

Com o crescimento exponencial (?) da Internet, espera-se que o esgotamento do número de AS disponível para alocação esgote-se por volta do ano de 2015, no mais otimista dos casos. Por isso foi criada uma extensão ao tradicional AS de 2 bytes para um número AS de 4 bytes (ASN32) e este padrão foi publicado oficialmente pelo IETF no RFC 4893 no início de 2007. O padrão garante a compatibilidade entre os antigos e os novos números de AS de forma a garantir a interoperabilidade entre os dois padrões, já que esta informação deve ser utilizada dentro do protocolo BGP (pelo atributo AS_PATH) que é visível através de toda Internet.

Alguns grandes fabricantes de equipamentos de rede já estão se adaptando ao novo padrão, como é o caso da Juniper que a partir da versão 9.x do JunOS já suporta ASN32. Vale lembrar que o padrão para utilização de communities dentro do BGP também será ligeiramente alterado (para a Juniper, por exemplo, o padrão para communites com o ASN32 será 334324L:132 para o ASN 334324 e target 132). A Cisco diz possuir o código para ASN32 implementado na versão 12.5T do IOS que deve estar disponível em breve.

Vale lembrar que os primeiros testes desse novo padrão foram feitos com software-routers como o openbgpd e o Quagga. Para mais informações sobre o como os fabricantes estão se preparando e os testes realizados até agora na Internet visite o Wiki AS4 sobre ASN32.

Mais informações:

Configuração de portas Gigabit Ethernet

Esta noite estava vendo um outro blog sobre redes quando encontrei uma frase ao mesmo tempo trágica e engraçada (como a frase foi escrita em inglês, manterei na língua original): "Repeat after me. I will not force a switch to 1000/Full, even if some idiot insists that I should."

Essa é, com certeza, umas das discussões mais antigas que eu já vi. Alguns dizem que sim, alguns dizem que não, enfim... Apesar do assunto ser bastante comentado em diversos lugares, como por exemplo a página Techworld, muita gente custa a acreditar! :)

Por isso o meu grande amigo Thiago Siqueira fez um ótimo dever de casa há algum tempo atrás e eu gostaria de compartilhar para também ficar registrado aqui.

Acontece que no início da implementação do padrão Gigabit Ethernet (IEEE 802.3z) a especificação não era clara a respeito de utilizar auto-negociação ou configurar manualmente a interface para half ou full-duplex em portas gigabit e isso fez com que os fabricantes - talvez utilizando o mesmo código que utilizavam para portas 10/100 ou ainda por causa do comodismo em continuar configurando um novo padrão com velhos costumes - implementassem de forma diferente o padrão Gigabit Ethernet em UTP, uma herança da forma como foi definido e implementada a auto-negociação do padrão IEEE 802.3u (Ethernet 100 MBps). Com o passar do tempo, surgiu toda essa confusão.

Para o padrão IEEE 802.3 (Ethernet) o uso de auto-negociação para interfaces 1000BASE-T é MANDATÓRIO. Consulte o documento a seguir para mais informações (página 603, item A, anexo 28A, cláusula 28D.5): http://standards.ieee.org/getieee802/download/802.3-2005_section2.pdf

Muito tempo depois a possibilidade de configuração fixa para full ou half-duplex no padrão Gigabit Ethernet foi possível (e aceitável) para que garantisse a compatibilidade entre os equipamentos que seguiam o padrão (mais novos) e os equipamentos mais velhos (do início da implementação do padrão Gigabit Ethernet). Hoje todos os fabricantes implementam corretamente (ou pelo menos deveriam implementar) o padrão estabelecido pelo IEEE em 1998.

quinta-feira, 31 de julho de 2008

Teste o seu DNS recursivo!


É possível testar se o seu DNS recursivo está atualizado utilizando (além do teste disponível na página do Dan Kaminsky) o teste on-line disponibilizado pelo DNS-OARC ou através da linha de comando abaixo.

$ dig +short porttest.dns-oarc.net TXT

porttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
"x.x.x.x is GREAT: 26 queries in 5.1 seconds from 26 ports with std dev 18219"

Para testar on-line (com gráficos!!) :-), basta clicar AQUI.

Cisco BGP default-information originate

Não é um cenário muito comum utilizar uma rota default dentro do BGP para roteamento na Internet, no entanto, uma rota default é muito útil quando estamos falando de redes baseadas na tecnologia MPLS (utilizando BGP entre o CE e o PE), principalmente em topologias HUB-and-SPOKE.

Basicamente, é possível anunciar uma rota default de duas maneiras: 1) utilizando o comando default-information originate e 2) utilizando o comando network 0.0.0.0. A questão é: qual a diferença entre estes dois comandos ? (afinal de contas, os dois anunciam uma rota default! :-)

1) Default-information originate

Para utilizar o comando default-information originate dentro da configuração do BGP é necessário que uma rota default seja redistribuída para o BGP de outro protocolo de roteamento (dinâmico ou estático). Por exemplo:

ip route 0.0.0.0 0.0.0.0 189.1.1.1
!
router bgp 65000
default-information originate
redistribute static

2) Network 0.0.0.0

Se utilizarmos o comando network 0.0.0.0 dentro da configuração do BGP, desde que uma rota default esteja instalada na tabela de roteamento, o roteador passará a anunciar uma rota default para seus peers BGP (independente de como esta rota default foi instalada na tabela, via protocolo dinâmico ou uma simples rota estática).
ip route 0.0.0.0 0.0.0.0 189.1.1.1
!
router bgp 65000
network 0.0.0.0
Mais informações em: Cisco IP Routing Protocols Command Reference: Default-information originate

quarta-feira, 23 de julho de 2008

Você está vulnerável a DNS cache-poisoning?

Seguindo os artigos já publicados neste blog sobre a vulnerabilidade de cache-poisoning do BIND, descoberta acidentalmente durante as pesquisas de Dan Kaminsky, ainda há muito o que ser feito para que se chegue realmente a solução definitiva.

Mas... como saber de forma prática e rápida se seus servidores de DNS estão vulneráveis a este problema? A dica é para um applet disponível no blog DoxPara (do próprio Dan) que faz a validação. Basta clicar em Check My DNS.

O seu DNS ainda está vulnerável?

Bem, nem tudo está perdido, pois há serviços na Internet que fazem a resolução de nomes (sim, é o que o DNS/BIND faz) "de graça" e em servidores que contem os últimos patches de segurança aplicados. Segundo a OpenDNS, os servidores deles não possuem esta vulnerabilidade.

É ver para crer.

terça-feira, 22 de julho de 2008

Qual é a versão do seu BIND?

Esse é um problema velho, muito velho... Velho mesmo! Mais ainda existem servidores de DNS que possuem essa feataure habilitada. Nos tempos em que se fala em vulnerabilidades do protocolo DNS (que sempre existiram, é bom ressaltar) muita gente além de não atualizar a versão do BIND, não segue as melhores práticas de segurança para servidores de DNS.

É possível, com uma query de DNS simples, descobrir a versão do BIND instalada do servidor de DNS (e não é só do BIND não...). Os exemplos abaixo são de dois grandes provedores de Internet no Brasil:

$ nslookup -type=txt -class=chaos version.bind ns1.xxxx.com.br
Server: ns1.xxxx.com.br
Address: 200.xxx.x.172#53

version.bind text = "9.3.1"

$ dig @ns1.xxxxxxx.com.br version.bind chaos txt
;; Warning: Message parser reports malformed message packet.

; <<>> DiG 9.3.4-P1 <<>> @ns1.xxxxxxx.com.br version.bind chaos txt
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4419
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;version.bind. CH TXT

;; ANSWER SECTION:
version.bind. 5 IN TXT "Served by POWERDNS 2.9.20 $Id: packethandler.cc 539 2005-11-11 11:17:47Z ahu $"

;; Query time: 34 msec
;; SERVER: 200.xxx.xxx.4#53(200.234.202.4)
;; WHEN: Tue Jul 22 17:04:44 2008
;; MSG SIZE rcvd: 121
Para não permitir que o BIND forneça sua versão com este tipo de consulta é necessário configurar a opção:
options {
version "Not disclosed";
}
Para mais informações, consultar este link.

Vulnerabilidades no DNS

Se você esteve viajando pela galáxia neste mês de férias e chegou na Terra agora provavelmente não percebeu que no último dia 8 de julho o US-CERT em coordenação com os principais desenvolvedores de sistemas de DNS (tal como o ISC e a Microsoft) divulgou um alerta sobre algumas vulnerabilidades inerentes ao protocolo DNS e que estão presentes em quase todas as implementações disponíveis hoje. Estas deficiências do protocolo DNS destacadas no alerta do US-CERT podem levar ao envenenamento do sistema de cache do DNS (DNS cache poisoning). Antes de você terminar de ler esse post, vá aplicar os patches nos seus servidores de DNS!

Estas vulnerabilidades vieram à tona devido ao trabalho desenvolvido por Dan Kaminsky da IOActive e o resultado nós poderemos ver em uma apresentação na próxima Black Hat no dia 7 de agosto ou talvez um pouco mais cedo já que o SANS ISC divulgou hoje que esta vulnerabilidade talvez já esteja sendo explorada.

É certo, também, que a idéia básica de spoofing no DNS não é nova. Paul Vixie - que para quem não conhece é o criador do BIND - destacou essa vulnerabilidade em um artigo da Usenix em 1995:

"With only 16 bits worth of query ID and 16 bits worth of UDP port number, it's hard not to be predictable. A determined attacker can try all the numbers in a very short time and can use patterns derived from examination of the freely available BIND code. Even if we had a white noise generator to help randomize our numbers, it's just too easy to try them all."
Portanto, mais uma vez, mantenha os seus sistemas atualizados (leia novamente a frase anterior). Vale lembrar também que a aplicação das atualizações de segurança não garantem a total segurança de um servidor pois, como já foi comentado, este problema é intrínseco do protocolo. A única forma de resolver definitivamente este problema é a adoção de DNSSEC, o que hoje é quase impossível.

Mais informações em:

sexta-feira, 18 de julho de 2008

Cisco IOS 12.4(20)T e 12.4(15)T

Este mês a Cisco lançou para utilização a versão 12.4(20)T do IOS. Com esta versão a Cisco também anunciou algumas mudanças interessantes que quero destacar aqui. Algumas plataformas deixam de ter suporte no ciclo de desenvolvimento a partir da versão 12.4(20)T e passam a ter suporte somente na versão 12.4(15)T e nas atualizações já previstas no release notes de cada uma das plataformas. As plataformas que deixam de ter suporte são:


• Cisco SOHO 90 Series

• Cisco 831, 836, and 837 Series

• Cisco 1701, 1711, 1712, 1721, 1751, 1751-V, and 1760 Series

• Cisco 2610XM-2611XM, 2620XM-2621XM, 2650XM-2651XM, and 2691 Series

• Cisco 3631 and 3660 Series

• Cisco 3725 and 3745 Series

• Cisco 7400 Series

• Cisco AS5850 Universal Gateway


Para mais informações consulte o Cisco IOS Software Release 12.4T Q&A. Enquanto isso, a Cisco também anunciou que a versão 12.4(20)T não terá mais suporte à fast switching (entre muitas outras coisas), o que nos deixará apenas com process switching ou CEF. Há também alguns avanços consideráveis para as features existentes, como por exemplo a possibilidade de fazer logging do CEF ou a captura de pacotes diretamente no IOS. Para mais informações sobre novas features consultar o Cisco IOS Software 12.4T Features and Hardware Support.

terça-feira, 10 de junho de 2008

"Troca de placa remota" no Cisco IOS

OIR - Online Insertion and Removal - é uma funcionalidade que permite que um novo hardware seja adicionado com o equipamento ainda ligado (isto é, sem a necessidade de reboot). Após a inserção, o equipamento detecta o novo hardware e o inicializa para operação. O processo equivalente ocorre também para a remoção de uma placa. Este é um processo físico, ou seja, precisa de alguém fisicamente inserindo ou removendo a placa em um roteador.

No entanto, muitas das vezes este processo de OIR é solicitado pelo fabricando para que seja feita a reinicialização do hardware e não há a disponibilidade para ir rapidamente até o local e efetuar o procedimento.

Abaixo demonstrarei como é possível fazer, no 7500, o processo de OIR virtualmente, isto é, sem estar necessariamente fisicamente no mesmo local que o router:

  • para remover logicamente uma VIP (Versatile Interface Processor)
test rsp slot mask
test rsp stall
  • para ativar novamente a VIP:
test rsp slot unmask
test rsp stall
É claro que existem outros métodos de se efetuar um reset de uma placa, mas fica aqui a dica como registro de uma curiosidade.

segunda-feira, 2 de junho de 2008

Rcat Tool


Rcat (Root Cause Analysis Tool) é uma ferramenta desenvolvida por Anthony Lambert (Orange Labs) para análise de problemas no roteamento eBGP. Esta ferramenta tem uma interface não muito amigável mas é bem completa e interessante. Para testá-la, basta entrar com um período (não maior que 7 dias), depois um número de sistema autônomo, por exemplo "as10429" no campo logical query, digitar o código e clicar no botão Search. A seguir, basta navegar pelos resultados.

NANOG 43 - Brooklyn, NY


Começou ontem na região do Brooklin em New York a NANOG 43 com transmissão ao vivo desde ontem até o encerramento na próxima quarta-feira. O programa completo pode ser encontrado aqui. Algumas ferramentas comentadas aqui (como o iBGPlay) serão apresentadas nesta reunião.

domingo, 1 de junho de 2008

Shmoocon 2008: Vídeos Disponíveis

Os vídeos da Shmoocon 2008 estão disponíveis aqui. Aguardamos os vídeos do GTER/GTS... :-)

Perícia Forense em Web Browsers no GTER/GTS

A Equipe Nexthop participou massivamente no evento GTER/GTS

Hoje acompanhamos o evento do GTS, que teve um público excelente. A primeira palestra foi a respeito de Perícia Forense em Web Browsers, com o Palestrante Ricado Kléber Martins Galvão, CEFET/RN (http://www.cefetrn.br/). O assunto é muito atual e de muito valia para quem precisa encontrar ferramentas certas no dia-dia. A Palestra foca também nas necessidades dos perítos forenses cumprirem Normas e Procedimentos no ato de coleta dos dados que serão analisados.

O Ricardo indicou várias ferramentas (OpenSource, Freeware e Shareware) de análise forense em Web Browsers:

- Pasco
- Galleta
- Web Historian
- NetAnalysis
- Cache View
- IE History Viewer
- IE HistoryView
- IE CookiesView
- IE CacheView
- Mozilla HistoryView
- Mozilla CacheView
- Mozilla CookiesView

- wbf (Web Browser Forensics)
- Cache Monitor
- IE Cache Auditor
- Internet Cache Explorer
- STG Cache Audit
- Web Cache Illuminator
- Index.dat Analyzer (anti-forense)
- IE History Manager (anti-forense)

Ferramentas não Específicas para WEB:

- FTK - Forensic Tool Kit
- EnCase
- Autopsy / Sleuthkit

Kits recomendados para análises:

- Helix (recomendado)
- Professional Hackers Linux Assault Kit (PHLAK)
- Knoppix security tools distribution (Knoppix-std)
- Penguin Sleuth Kit Bootable CD
- Forensic and Incident Response Environment Bootable CD (FIRE)

Caso você queira praticar, existe material para utilizar as ferramentas em:

- Artigo de um caso hipotético na Securityfocus: Web Browser Forensics (Parts 1 and 2)

- Material para prática aqui.

Essas ferramentas são constantemente utilizadas pela Polícia Federal do Brasil. E vale muito a pena vocês darem uma olhada na apresentação que está aqui.

O vídeo da apresentação será disponibilizado para todos no Sítio do GTS.

Obrigado especial para o Ricado do CEFET/RN que agrupou esses links.

sábado, 31 de maio de 2008

iBGPlay "all'italiana"

Além do BGPlay (ferramenta desenvolvida dentro do project NCC da RIPE e já comentada aqui no blog), uma outra ferramenta interessante para visualização de roteamento entre domínios (ou sistemas autônomos) é a iBGPlay (http://www.ibgplay.org), projeto da Universidade de Roma na Itália e uma espécie de atualização do BGPlay. A iBGPlay possui praticamente os mesmos parâmetros de configuração e uma interface mais amigável. 

sexta-feira, 30 de maio de 2008

Diminuindo o tempo de reboot do IOS

Na versão 12.3(2)T do IOS da Cisco foi incluída uma funcionalidade que torna possível otimizar o tempo total de reboot de um roteador. Essa nova funcionalidade é chamada de Warm Reload/Upgrade.

O grande ganho na verdade está em fazer o carregamento e a descompressão da imagem do IOS na memória RAM em paralelo com a que está sendo executada no momento. A partir daí quando é efetuado o reload, como estes passos de carregamento e descompressão já estão feitos, o tempo de reboot se limita apenas a inicialização e a execução do IOS.

Estimativas apontam para uma redução média de até 66% do tempo total de reboot, ou seja, se o reboot normal demora cerca de 3 minutos, com o Warm Reload estima-se que demore apenas 1 minuto.

Esta funcionalidade pode ser muito útil para diminuir o downtime do equipamento em situações de upgrade de IOS ou em casos de reboots espontâneos (por exemplo, por causa de um crash).

Recomendo fortemente a leitura da documentação no site da Cisco (link acima), principalmente porque este funcionalidade não deve ser utilizada muitas vezes consecutivas, pois pode causar problemas ao funcionamento do roteador (por exemplo, de fragmentação de memória).

segunda-feira, 26 de maio de 2008

BGP, route servers e afins

Para quem acompanha o blog já deve ter observado as outras dicas a respeito dos route servers. Estes são roteadores reais (ou simulados através de software), geralmente a livre disposição para acesso remoto (via telnet) para troubleshooting de problemas de anúncios de rotas BGP e alcançabilidade pela Internet.

A dica agora é para o site CiscoNet que representa e dispõe no mapa Mundi os route servers disponíveis bastando apenas um click para que se acesse o route server desejado.

Para quem deseja ir mais a fundo neste assunto há neste site muitas outras informações interessantes além do acesso aos route servers como noções e configuração de BGP, sites de whois, listas de servidores de dns entre outras.

sexta-feira, 23 de maio de 2008

Reunião do GTER/GTS, Salvador/Bahia

O comitê de programa da reunião conjunta do Grupo de Trabalho de Engenharia e Operação de Redes e do Grupo de Trabalho em Segurança (25a. Reunião do GTER e GTS-11) divulgou nesta última semana o programa de apresentações. Este evento acontecerá em Salvador-BA nos dias 31 de maio e 1o. de junho logo após o término da reunião do LACNIC XI (que acontece de 26 a 30 de maio). O destaque dos três eventos (LACNIC/GTER/GTS) será a grande discussão em torno do protocolo IPv6. No LACNIC XI estará disponível para os participantes conectividade wireless com IPv6 nativo (com e sem interoperabilidade com IPv4) para que os participantes possam testar suas aplicações com este protocolo, seguindo o modelo utilizado nas últimas reuniões do IETF e NANOG.

Outro destaque é a apresentação do Eduardo A. Reis sobre um estudo de casos sobre suporte ao protocolo IPv6 em firewalls. Um bom material sobre este assunto foi publicado pela ICANN através do Security and Stability Advisory Committee em outubro de 2007. É um documento que faz uma análise sobre o suporte ao protocolo IPv6 em firewalls comerciais (Survey of IPv6 Support Among Commercial Firewalls - SAC021).

Fica a dica deste evento para quem puder ir até Salvador... Ah! E para aqueles que não puderem ir até lá o GTER/GTS possui transmissão ao vivo via streaming Windows Media ou Real Player. Mais informações no site do evento: http://gter.nic.br.

quarta-feira, 21 de maio de 2008

Como fazer o backup das configurações do PuTTY

Para quem não conhece, o PuTTY é uma das ferramentas mais utilizadas para se realizar a administração remota a equipamentos através dos protocolos telnet, rlogin e ssh. Ele é um software pequeno e uma das grandes vantagens é que não requer a instalação local para funcionar.

No entanto, muitos usuários do PuTTY já se depararam com o problema de perder as configurações do PuTTY quando se formata ou se migra de uma máquina cliente para outra. Recriar estas configurações do PuTTY perfil a perfil (IPs dos equipamentos, portas remotas, tipo de emulação de terminal, cores do terminal, etc) pode se tornar MUITO desagradável.

O ponto chave é que o PuTTY não cria um arquivo no filesystem com as configurações de todos os perfis de acesso, mas sim estas informações ficam "escondidas" dentro do registro do Windows.

Para fazer o backup das configurações o procedimento abaixo deve ser executado:
  • Abrir o regedt32 do Windows
  • Buscar pela chave de nome "SimonTatham" que fica no caminho HKEY_CURRENT_USER\Software\SimonTatham
  • Ao localizar a chave SimonTatham pressione o botão direito do mouse e selecione a opção Exportar
  • Salve esta chave como putty.reg
  • Copie esta chave para algum dispositivo de armazenamento externo (pen drive, disco externo, etc)

Para fazer o restore das configurações é muito simples:
  • Copie o arquivo putty.reg para o micro desejado
  • Pressione o botão direito do mouse sobre o arquivo e selecione a opção Mesclar

Pronto com isso deve ser possível manter as configurações de seu PuTTY!

terça-feira, 25 de março de 2008

Link: Undocumented Cisco Commands

Não sei muito bem se uma lista de comandos não-documentados da Cisco pode ajudar em alguma coisa... No entanto, achei uma lista bastante completa e interessante (talvez um pouco desatualizada). Alguns comandos que figuram como não-documentado já possuem uma documentação e aparecem no prompt de ajuda interativa do IOS. Isso mostra também que alguns deles - tão utilizados hoje em dia - apareceram pela primeira vez um pouco, digamos, escondidos.

segunda-feira, 24 de março de 2008

Entendendo NAT em Roteadores Cisco

Há alguns anos, com o esgotamento dos endereços IPv4 cada vez mais próximo, foi necessário encontrar uma alternativa para diminuir a velocidade de alocação de endereços IPv4 e aproveitar ainda melhor aqueles que já haviam sido alocados para os provedores de serviço (RFC-1631). Uma dessas alternativas foi a utilização de muitos endereços privados (conforme definido no RFC-1918) que posteriormente deveriam ser traduzidos para um (ou mais) endereço público para assim haver conectividade entre endereços públicos da Internet e endereços privados. Essa estratégia ficou conhecida como NAT (Network Address Translation).

A Cisco, por sua vez, possui uma terminologia e uma maneira particular de implementar os três principais tipos de NAT (estático, dinâmico e tradução de portas), no entanto, existem algumas informações importantes sobre roteamento e NAT Virtual Interfaces que devem ser entendidas também, e é isso que vamos tratar neste post. Para começar, é necessário entender a terminologia local e global, assim como inside e outside.

  • Inside local address: é o endereço atribuído a interface de rede de uma estação, por exemplo (escopo local).
  • Inside global address: é o endereço público que representa um ou mais endereços inside local (escopo global ou a Internet).
  • Outside local address: é a forma como um endereço IP público é visto na rede interna. Geralmente este endereço é roteado somente pelos roteadores internos (não é roteado na Internet e, portanto, possui um escopo local).
  • Outside global address: é um endereço público da Internet (é roteado na Internet).
É claro, também, que esta terminologia existe para nos auxiliar a entender onde estas definições e posteriores configurações serão utilizadas, já que os roteadores não possuem a inteligência necessária para distinguir um endereço público de um endereço privado (no final, serão somente zeros-e-uns). A figura abaixo (fornecida gentilmente pela Cisco) representa estas definições.


Essas definições serão importantes para escolher quais interfaces serão classificadas como inside e outside e como serão construídas as regras de tradução.

Seguindo o exemplo da figura abaixo, um host com endereço IP 192.168.0.1 (inside local) envia um pacote para o endereço 72.72.72.1 (DA - outside local e outside global). Ao passar (da interface INSIDE para OUTSIDE) por um roteador com NAT habilitado poderá ter traduzido o endereço de origem (SA) de 192.168.0.1 (inside local) para 200.200.200.1 (inside global). Esta tradução permite que o host 192.168.0.1 estabeleça uma comunicação com o host 72.72.72.1. O pacote com a resposta do host 72.72.72.1 terá como endereço de destino 200.200.200.1 (inside global) e novamente ao passar pelo roteador com NAT habilitado será traduzido - agora o endereço de destino - de 200.200.200.1 para 192.168.0.1 (inside local), fazendo com que os pacotes cheguem até o seu destino correto. Exemplo:


Com isso, podemos ver como fica a configuração para um ambiente com NAT estático como é exemplificado na figura acima.
ip nat inside source static 192.168.0.1 200.200.200.1

! interface INSIDE
interface fast0/0
ip nat inside

! interface OUTSIDE
interface serial0/0
ip nat outside
A utilização de "inside source" ou "outside source" na regra de tradução (NAT) altera a forma como é traduzido o endereço dos pacotes de acordo com o sentido do tráfego:

- ip nat inside source
  • Traduz o endereço de ORIGEM dos pacotes que trafegam da interface inside para outside.
  • Traduz o endereço de DESTINO dos pacotes que trafegam da interface outside para inside.
- ip nat outside source
  • Traduz o endereço de ORIGEM dos pacotes que trafegam da interface outside para intside.
  • Traduz o endereço de DESTINO dos pacotes que trafegam da interface inside para outside.
Podemos agora verificar se está tudo funcionando conforme o planejado com o seguinte comando:
Router#show ip nat translations

Pro Inside global Inside local Outside local Outside global
--- 200.200.200.1 192.168.0.1 --- ---
Ainda temos dois tipos de NAT que não serão discutidos aqui, tal como o NAT dinâmico e a tradução de porta (também conhecido como PAT, ou Port Address Translation). Estes outros tipos de NAT seguem o padrão apresentado acima.

Vamos analisar uma outra questão importante quando estamos trabalhando com NAT...

NAT Virtual Interface

Um dos problemas que podemos enfrentar quando habilitamos NAT utilizando interfaces INSIDE e OUTSIDE é a necessidade de inserir rotas para os endereços traduzidos. Isso acontece pois a ordem de tradução e roteamento ocorre em momentos diferentes durante o processamento de um pacote dependendo do sentido do tráfego. No sentido inside-to-outside a tradução é feita DEPOIS da decisão de roteamento. No sentido contrário (outside-to-inside) a tradução acontece primeiro. A ordem completa pode ser encontrada aqui.

A partir da versão 12.3T a Cisco introduziu o conceito de NAT Virtual Interface (NVI)*. Dessa forma, a tradução dos endereços ocorre de forma simétrica e não é necessário inserir rotas para os endereços traduzidos. Quando uma interface está habilitada para fazer NAT utilizando NVI, o pacote que adentrar esta interface será roteado para a interface NVI (onde ocorre a tradução) e depois roteado mais uma vez utilizando a tabela de roteamento. A configuração utilizando NVI para o exemplo que citamos acima é a seguinte:
ip nat source static 192.168.0.1 200.200.200.1

interface fast0/0
ip nat enable

interface serial0/0
ip nat enable
Veja que dessa forma não é necessário declarar nenhuma interface como inside ou outside, ou mesmo declarar o sentido de tradução no comando de NAT estático. Esta nova funcionalidade resolve também o problema de tradução para endereços roteados para uma mesma interface de entrada (já que pode existir casos em que um pacote pode entrar por uma interface outside e nunca alcançar a interface inside correspondente, conforme descrito neste artigo).

Para encerrar este post, gostaria de reforçar que até aqui não foi apresentado nenhum mecanismo ou forma de segurança relacionada com a utilização (ou a não utilização) de NAT, apesar de, no passado, muitos profissionais acreditarem que a simples utilização de tradução de endereços poderia aumentar a segurança de um ambiente...

Veja também:

(*) A interface NVI0 que está presente nos roteadores que possuem NAT habilitado (a partir da versão 12.3T) é a NAT Virtual Interface:

Router# show interfaces
(...)
NVI0 is up, line protocol is up
Hardware is NVI
Interface is unnumbered. Using address of NVI0 (0.0.0.0)
(...)

quinta-feira, 20 de março de 2008

Um Pouco de História


Há algum tempo atrás, navegando por águas desconhecidas, encontrei a história do programa PING. Aquele que todos usamos para testar a conectividade entre um ponto e outro da rede e, ao contrário do que muitos acreditam, o nome PING não é nenhum acrônimo (ou coisa parecida). Este nome foi inspirado no som produzido por um sonar ao encontrar um objeto... Toda esta história está na página do criador do programa, o sr. Mike Muuss.

Esta história me fez lembrar uma outra história passada já em terras brasileiras e contada também por quem fez (e continua fazendo) história. "Os Primeiros Pings" é o título de uma reportagem publicada no jornal Estado de São Paulo em 1/11/2004 quando houve a "comemoração" dos 35 anos de "criação" da Internet e descreve como o Brasil - representado na época pela Fapesp - conectou-se pela primeira vez à Internet. Demi Getschko, um dos responsáveis pelos primeiros pings disparados do Brasil, é quem assina esta reportagem.

Duas histórias que valem a pena, nem que seja para puxar um papo high-tech com o seu avô na macarronada do próximo domingo! :-)

Atualizado em 24/03/2008: Como o link para a reportagem "Os Primeiros Pings" geralmente não funciona, estou colocando ela aqui na íntegra:



Os primeiros "pings"

Demi Getschko

A Bitnet já estava em uso há uns dois anos. Na linha que ligava a Fundação de Amparo à Pesquisa do Estado de São Paulo (Fapesp) ao FermiLab, em Batavia, Illinois, rodava um procolo da DEC (o DecNet) e, sobre ele, o protocolo da IBM usado para o Bitnet (o RSCS). E isso em 4800 bps!

Um belo dia, entra em minha sala o Geraldo (prof. dr. Geraldo Lino de Campos): - Demi, a tendência clara nos EUA é uma migração em massa para TCP/IP, Internet. Precisamos incluir TCP/IP na linha.

Se havia alguém que podia fazer isso – colocar três protocolos, sérios e pesados, numa linha de 4800 – era Gomide (Alberto Courrege Gomide), o mago do software na Fapesp. Ele foi atrás de soluções e encontrou o MultiNet, do melhor jeito que dava. E o troço nem barato era, especialmente para os padrões acadêmicos!

Afinal, chegou a caixa com as fitas (DecTape à época). O Joseph (Joseph Tannous Moussa, um libanês que tinha feito computação na USP e trabalhava na Fapesp) não resistiu à tentação e começou a instalar o pacote. Janeiro, período de férias coletivas na Fapesp e, ainda por cima, sábado. Passamos a tarde inteira instalando o Multinet. Afinal, funcionou! Restava acertar o lado de lá. Gomide, numa visita ao Fermilab, soube que o laboratório estava também em fase de passar ao TCP/IP, integrando a EsNet (Energy Sciences Network): “assim que o Fermi estivesse conectado à internet, nos também estaremos!”

Agora, buscar endereços!: para estar na rede, alguém precisa de números IP. E números IP quem distribui é a IANA (Internet Assigned Numbers Authority). IANA é a outra forma com que era conhecido Jon Postel, um dos criadores da rede e uma das ausências ainda hoje mais sentidas e difíceis de suprir na Internet (Postel morreu em 1998).

Michael, da PUC do Rio (prof. Michael Stanton) já havia pedido e conseguido o primeiro subconjunto de números IP para uma instituição brasileira: a rede classe B 139. 82.*.*. Pedimos ao Postel, de cara, três classes B: para a Unicamp, a USP e a Fapesp, e recebemos as 143.106.*.*; 143.107.*.*; 143.108.*.* . Cenário completo e armado. Nossa "poderosa" linha de 4800 bpd transportaria também pacotes TCP/IP sobre o DecNet básico, via software. A linha já estava com 100% de ocupação, 98% do tempo mas, mesmo assim, alguns pacotes conseguiram pingar entre o fpsp.fapesp.br e o fnal.gov. Era janeiro de 1991 e a Internet chegava, em conta-gotas, ao Brasil...

Demi Getschko, é pioneiro da internet no Brasil.

NANOG 42 - Vídeos

Mais um feriado se aproxima e se você está sem o que fazer pode aproveitar para ver algumas apresentações da última reunião da NANOG. Os vídeos estão disponíveis através da Agenda de apresentações.

terça-feira, 18 de março de 2008

Cisco IOS - Nomenclatura e Versões (Parte 2)

Para completar as informações sobre o sistema operacional da Cisco é necessário citar a classificação que é atribuída a cada imagem e as famílias principais utilizadas pela Cisco atualmente.

A classificação que cada imagem recebe permite-nos avaliar qual versão deverá ser utilizada em uma infraestrutura de rede, dado os requisitos de funcionalidade e estabilidade. Toda a trilha de classificações abaixo têm início em uma major release do IOS. Lembrando que a major release é a versão principal do IOS, por exemplo, 12.1, 12.2, 12.3, etc. São elas:

  • Limited Deployment (LD): uma major release do IOS é classificada como LD após o seu lançamento comercial (FCS ou First Commercial Shipment) e antes de alcançar a classificação GD (General Deployment).
  • General Deployment (GD): em um determinado momento no ciclo de vida do desenvolvimento de uma major release a Cisco poderá classificar uma versão como GD. Esta classificação pode ser atribuída somente à uma major release e é baseada principalmente no feedback recebido dos clientes sobre a estabilidade da versão. Durante o ciclo de vida de uma versão GD, todas as versões subsequentes (somete com correções de bugs e problemas de segurança) serão consideradas GD.
  • Early Deployment (ED): são as versões baseadas em major releases que, no entanto, possuem novas funcionalidades, atualizações de segurança e correção de bugs. O propósito das versões ED é permitir que os clientes possam utilizar novas funcionalidades mais rapidamente. Como as versões classificadas como ED não são totalmente estáveis, é aconselhável utilizá-las somente caso não haja uma versão GD ou LD que possua suporte a uma determinada funcionalidade.
  • Deferral (DF): O propósito de classificar uma verão como DF é anunciar que esta versão não estará mais disponível para download e que já existe uma nova imagem para substituí-la. A partir deste momento a Cisco aconselha que todos os seus clientes atualizem uma possível versão DF para a sua substituta.
Com o passar do tempo, a Cisco restringiu o desenvolvimento do IOS para três famílias principais. São elas: T, S e XR. Estas famílias seguem objetivos (funcionalidades e suporte a hardware) e ciclo de vida diferenciados e, portanto, são aconselhadas para diferentes propósitos, como poderemos ver a seguir:

-Train T: Possui basicamente duas trilhas (12.3/12.4 e 12.4T) com várias funcionalidades para (principalmente) roteadores de acesso e redes comerciais.
  • 12.3/12.4: possui as novas funcionalidades adicionadas às versões T anteriores e as correções de bugs e problemas de segurança.
  • 12.4T: possui suporte a novos hardwares e funcionalidades.
-Train S: Esta família é dedicada para os provedores de serviço (Service Provider) e possui maior suporte para roteadores (e/ou switches) do núcleo destes provedores (por exemplo, os modelos 7600 ou 6500).
  • 12.2SB: Broadband and Leased-Line Aggregation, and MPLS Provider Edge (PE).
  • 12.2SX: functionality and hardware for high-end Ethernet LAN switching for Enterprise access, distribution, Core and data center networks.
  • 12.2SE/12.2SG: for mid-range and low-end Ethernet LAN switching for Enterprise access and distribution networks, and mid-range and low-end Metro Ethernet for Service Provider edge networks.
  • 12.2SR: for high-end Metro Ethernet and MPLS PE for Service Provider
-Train XR: desenvolvida para o Cisco CRS-1 (Carrier Routing System) e para o Cisco XR 12000 Series para provedores de serviço, visando principalmente plataformas que necessitam de alto desempenho (possivelmente chegando a escala de terabits). Atualmente na versão 3.2.

Além disso, a Cisco recomenda a instalação de um tipo de imagem de acordo com a plataforma. As principais recomendações estão dispostas abaixo (uma lista completa e atualizada pode ser encontrada aqui):
  • Roteadores 800, 1700, 2600, 2800, 3700 e 3800 (low-range): 12.4 ou 12.4T;
  • Roteadores 7200 e 7301: 12.4T ou 12.2SB;
  • Roteadores 7500: 12.4 ou 12.0S;
  • Roteadores 7600: 12.2SR;
  • Roteadores 12000: IOS-XR ou 12.0S;
  • Roteadores CRS-1: IOS-XR;
  • Switches Catalyst 2970, 3560 e 3750: 12.2SE;
  • Switches Catalyst 4500 e 4900: 12.2SG;
  • Switches Catalyst 6500:12.2SX;
Com isso encerramos este pequeno resumo sobre como a Cisco trata a nomeclatura, a classificação (dentre as plataformas) e as versões do Cisco IOS.

Veja também: