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.
quarta-feira, 7 de janeiro de 2009
Perigo! Certificados SSL que utilizam o MD5 podem ser forjados
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:
- Informações sobre SFP no blog Nexthop.
- Cisco Small Form-Factor Pluggable (SFP) Transceiver Modules Maintenance and Troubleshooting.
- Cisco IOS Interface and Hardware Component Command Reference: show hw-module subslot transceiver.
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.
# 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.
Figura 1
Figura 2Para mais informações:
- Cisco IOS IP SLA Configuration Guide (12.4T).
- SNMP MIB Lookup Tool CISCO-RTTMON-ICMP-MIB.
- Tobi Oetiker's MRTG
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.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
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
=====================
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)
- BugID Lookup Tool
- Command Lookup Tool
- Error Message Decoder Tool
- RMA/Service Order Status Tool
- TAC Service Request Query
Buscas
- Search Cisco
- Search Cisco Brazil
- Search Cisco Japan
- Search Cisco Latin America
- Search Cisco Russia
- Search Netpro Discussion
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
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.
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
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.1Se quisermos melhorar um pouco o nosso teste, podemos utilizar um ping estendido:
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
router#pingOu ainda, de forma mais rápida e resumida, o mesmo comando:
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
router#ping 10.10.10.1 repeat 10 size 1000Quando 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:
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
- 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.
router#ping 10.10.10.1 repeat 10 size 1000 data 4040Mais informações em:
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
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.
