ICMP Type and Codes

URL interessante para consulta de tipos de pacotes ICMP. Muito útil para análise de problemas de rede http://www.iana.org/assignments/icmp-parameters

ARP e ARP Flux

O protocolo ARP (Address Resolution Protocol) é utilizado para mapear endereços IP-para-ethernet e é tão utilizado que é quase impossível encontrar redes que utilizem um outro mecanismo para mapear endereços IP-para-ethernet (por exemplo, o mapeamento estático).

Quando uma estação deseja enviar um pacote para outra estação ou gateway de uma rede, é necessário, além de conhecer o endereço IP de destino, saber qual é o endereço ethernet (MAC address) de destino. Neste momento o protocolo ARP é acionado para encontrar a partir de um endereço IP o endereço ethernet correspondente.

Se o host-192-168-0-9 deseja enviar um datagrama IP para o host-192-168-0-100 então é necessário primeiro conhecer o endereço ethernet (mac address), que no exemplo abaixo é "00:0e:35:50:xx:xx":

host-192-168-0-9:~ $ tcpdump -ni en1 arp

tcpdump: verbose output suppressed, use -v or -vv for full protocol decodelistening on en1, link-type EN10MB (Ethernet), capture size 96 bytes

00:28:34.090647 arp who-has 192.168.0.100 tell 192.168.0.9

00:28:34.094124 arp reply 192.168.0.100 is-at 00:0e:35:50:xx:xx

Até aqui tudo normal. 

Quando um host com linux instalado possui duas ou mais interfaces de rede conectadas a um mesmo segmento de rede, podem ocorrer problemas com o mapeamento entre os endereços de camada 2 (ethernet) e camada 3 (IP). Isso ocorre pois o host responderá uma requisição ARP pelas duas interfaces de rede. Este comportamento pode gerar confusão na tabela de ARP do host que disparou a requisição ARP. Este comportamento é chamado de ARP Flux. É importante ressaltar também que este comportamento somente irá ocorrer quando duas ou mais interfaces estiverem conectadas à um mesmo segmento de rede (mesmo domínio de broadcast).

Um exemplo de ARP Flux:

[root@real-client]# arping -I eth0 -c 3 10.10.20.67

ARPING 10.10.20.67 from 10.10.20.33 eth0

Unicast reply from 10.10.20.67 [00:80:C8:7E:71:D4]  11.298ms

Unicast reply from 10.10.20.67 [00:80:C8:E8:1E:FC]  12.077ms

Unicast reply from 10.10.20.67 [00:80:C8:E8:1E:FC]  1.542ms

Unicast reply from 10.10.20.67 [00:80:C8:E8:1E:FC]  1.547ms

Sent 3 probes (1 broadcast(s))

Received 4 response(s)

Note que para um mesmo endereço IP há duas respostas com dois endereços ethernet distintos. Como não é possível saber qual das respostas será processada primeiro pelo host que disparou a requisição é possível que o endereço errado seja incluído na tabela ARP e a comunicação entre os dois hosts não aconteça.

Há basicamente quatro maneiras diferentes de resolver este problema. No kernel 2.4 pode-se utilizar a opção arp_filter do sysctl. Nos kernels 2.2 é necessário utilizar a opção hidden do systcl. Estas duas opções controlam a forma como são tratadas as requisições ARP por interface. 

As outras soluções envolvem a utilização do a ferramenta ip arp e a opção noarp route flag. A ferramenta ip arp e a filtragem do protocolo ARP está documentada aqui.

Como utilizar a opção arp_filter?

Basicamente a utilização da opção arp_filter (/proc/sys/net/ipv4/conf/$DEV/arp_filter) faz com que um host utilize a tabela de roteamento para encontrar por qual interface o mesmo deve encaminhar a resposta de uma requisição ARP, ao invés da opção padrão de encaminhar a resposta por TODAS as interfaces.

De modo geral, a utilização da opção arp_filter resolve o problema de ARP Flux e pode gerar problemas somente em cenários mais complexos onde é necessário controlar de forma mais detalhada as requisições e respostas do protocolo ARP.

Para alterar esta opção podemos utilizar "o bom e velho" echo, por exemplo, para a interface eth0:

user@host-192-168-0-9:~ $ echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_filter

Para mais informações sobre o protocolo ARP e o problema do ARP Flux, consultar este material (em inglês).

Check Point SPLAT Quick Tips

1) Overlapping Encryption Domains

Quando um servidor Smart Center Server (SCM) é utilizado para gerenciar mais de um firewall Check Point, podem existir problemas com a sobreposição do domínio da VPN (Encryption Domain ou enc dom). Neste caso é necessário definir manualmente o enc dom para que não haja esta sobreposição que poderá gerar problemas quando for utilizado o acesso remoto via Secure Client. Para verificar quais os gateways possuem sobreposição, devemos utilizar o comando (no SPLAT):

[Expert@smc-mgmt]# vpn overlap_encdom
The objects fw-01 and fw-02 have overlapping encryption domains.
The overlapping domain is:
10.10.0.0 - 10.10.255.255

Para mais detalhes consultar o sk32252.

2) Pen Drive USB no SPLAT

Para montar um pen drive no Check Point SecurePlatform utilizar o procedimento:

[Expert@fw]# mkdir /mnt/usb
[Expert@fw]# modprobe usb-storage
[Expert@fw]# mount -t vfat /dev/sdb1 /mnt/usb

Enjoy!

The day... the routers died

Depois de muito tempo... Um pouco de diversão e incentivo! :-)

Letra:

a long long time ago
i can still remember
when my laptop could connect elsewhere

and i tell you all there was a day
the network card i threw away
had a purpose - and worked for you and me….

But 18 years completely wasted
with each address we’ve aggregated
the tables overflowing
the traffic just stopped flowing….

And now we’re bearing all the scars
and all my traceroutes showing stars…
the packets would travel faster in cars…
the day….the routers died

Chorus (ALL!!!!!)
So bye bye, folks at RIPE 55
Be persuaded to upgrade it or your network will die
IPv6 just makes me let out a sigh
But I spose we’d better give it a try
I suppose we’d better give it a try

Now did you write an RFC
That dictated how we all should be
Did we listen like we should that day

Now were you back at RIPE fifty-four
Where we heard the same things months before
And the people knew they’d have to change their ways….

And we - knew that all the ISPs
Could be - future proof for centuries

But that was then not now
Spent too much time playing WoW

ooh there was time we sat on IRC
Making jokes on how this day would be
Now there’s no more use for TCP
The day the routers died…

Chorus (chime in now)
So bye bye, folks at RIPE 55
Be persuaded to upgrade it or your network will die
IPv6 just makes me let out a sigh
But I spose we’d better give it a try
I suppose we’d better give it a try

I remember those old days I mourn
Sitting in my room, downloading porn
Yeah that’s how it used to be….

When the packets flowed from A to B
via routers that could talk IP
There was data..that could be exchanged between you and me….

Oh but - I could see you all ignore
The fact - we’d fill up IPv4

But we all lost the nerve
And we got what we deserved!

And while…we threw our network kit away
And wished we’d heard the things they say
Put all our lives in disarray

The day…the routers died…

Chorus (those silent will be shot)
So bye bye, folks at RIPE 55
Be persuaded to upgrade it or your network will die
IPv6 just makes me let out a sigh
But I spose we’d better give it a try
I suppose we’d better give it a try

Saw a man with whom I used to peer
Asked him to rescue my career
He just sighed and turned away..

I went down to the net cafe
that I used to visit everyday
But the man there said I might as well just leave…

And now we’ve all lost our purpose..
my cisco shares completely worthless…

No future meetings for me
At the Hotel Krasnapolsky

and the men that make us push and push
Like Geoff Huston and Randy Bush
Should’ve listened to what they told us….
The day…the routers….died

Chorus (time to lose your voice)
So bye bye, folks at RIPE 55
Be persuaded to upgrade it or your network will die
IPv6 just makes me let out a sigh
But I spose we’d better give it a try
I suppose we’d better give it a try

Words and performance by Gary Feldman.

VPN Site-to-Site entre CheckPoint e Outros Fabricantes

Apesar de todos os fabricantes informarem que seus produtos estão de acordo com as especificações dos RFCs, na pŕatica as implementações dos protocolos variam de fabricante para fabricante.

Estas peculiaridades acabam impactando na interoperabilidade entre produtos e isso não deixa de ser verdade quando se quer configurar uma VPN entre CheckPoint e outros vendedores.

Muitos problemas na fase 2 ocorrem quando há configurações diferentes entre os gateways envolvidos no túnel VPN Site-to-Site. A curiosidade aqui é que o CheckPoint, por padrão, tenta efetuar supernetting sempre que possível das redes locais.

Por exemplo, se o encryption domain inclui duas subredes adjacentes, 172.30.32.0/22 e 172.30.36.0/22, o CheckPoint irá negociar uma única supernet: 172.30.32.0/21. Na hipótese do gateway remoto não ser da CheckPoint, a fase 2 pode não funcionar caso ele esteja esperando duas subredes (172.30.32.0/22 e 172.30.36.0/22) ao invés de uma única subrede (172.30.32.0/21).

Para resolver o problema de suppernetting, é possível configurar o CheckPoint para não utilizar a maior rede possível. Isso é feito configurando diretamente no SmartCenter Server:

# dbedit
Enter Server name (ENTER for 'localhost'):

Enter User Name: fwadmin
Enter User Password: abc123

Please enter a command, -h for help or -q to quit:
dbedit> modify properties firewall_properties
ike_use_largest_possible_subnets false

dbedit> update properties firewall_properties
firewall_properties updated successfully.

dbedit> quit
#

Após feitas as configurações aplique a política novamente e efetue os testes necessários na VPN. No próximo post irei detalhar como utilizar supernetting em VPNs CheckPoint mesmo que a funcionalidade de supernetting esteja desabilitada.

CheckPoint: Limpando a tabela de NATs

Em algumas versões do CheckPoint, principalmente as anteriores a NGX, há um bug no gerenciamento das entradas na tabela de NAT do firewall que faz com que ele não exclua as entradas dos NATs que não estão sendo mais utilizados. Segue abaixo um gráfico que demonstra exatamente este comportamento da tabela de NATs (gráficos de quantidade de entradas na tabela versus o tempo):


Acabar com este lixo de memória se resolve, na maioria das vezes, fazendo a reinicialização das paredes (Security Gateways), causando assim a indisponibilidade temporária do ambiente. Em situações de configurações de alta-disponibilidade (cluster ou failover) não fogem também a esta regra, visto que todas as paredes precisarão ser reinicidas simultanemente para que a tabela de NATs seja limpa.

Para tentar reduzir o tempo de indisponibilidade é possível utilizar um comando que limpa a tabela de NATs do firewall e que deve ser executado a partir dos Security Gateways (estejam em cluster ou não):

# fw tab -t fwx_alloc -x

Desta forma o impacto somente irá ocorrer para as conexões que possuem NAT e não para o tráfego global que passa pelo firewall.

Rancid e Fortinet

Para aqueles que como eu necessitam fazer backup da configuração de equipamentos da Fortinet, Daniel Epstein (thanks Daniel!!!) publicou na lista oficial do Rancid um patch para ser aplicado no Rancid para que o mesmo possa fazer backups dos Fortigate Firewalls rodando FortiOS 2.8 e 3.0.

Basicamente é utilizado os scripts do Netscreen (nlogin) para criar novos scripts para o Fortinet (fnlogin). Também precisei instalar a versão de desenvolvimento do Rancid (versão rancid-2.3.2a6) que foi testada no Debian pelo próprio Daniel e por mim no FreeBSD (instalando o Rancid via ports rancid-devel e depois aplicando o patch).

O Rancid, para aqueles que ainda não conhecem esta ferramenta, é um software para fazer backup e controle de configuração de equipamentos de rede que funciona com equipamentos dos principais fabricantes, dentre eles Cisco, Juniper, Extreme, Alteon, Force10, etc. Para saber mais, basta conferir o tutorial detalhado de como instalar e configurar o Rancid.

"Cisco comes back!"

Na tarde de ontem a Cisco anunciou quatro vulnerabilidades diferentes. A vulnerabilidade com o protocolo NHRP, no entanto, veio à tona esta manhã quando foi enviado para listas de discussão a prova de conceito de Martin Kluge (o pesquisador que reportou esta vulnerabilidade para a Cisco). Quem utiliza este protocolo deve corrigir esta falha o mais rápido possível, os detalhes estão na página do anúncio da Cisco (Cisco Security Advisory) .

- Cisco Security Advisory: Cisco IOS Secure Copy Authorization Bypass Vulnerability
- Cisco Security Advisory: Cisco IOS Next Hop Resolution Protocol Vulnerability
- Cisco Security Advisory: Cisco IOS Information Leakage Using IPv6 Routing Header
- Cisco Security Advisory: Voice Vulnerabilities in Cisco IOS and Cisco Unified Communications Manager

NAT Traversal

NAT ou Network Address Translation é, de uma forma muito simples, a tradução do endereço IP. Esta tradução pode ocorrer por muitos motivos, mas principalmente para que estações utilizando endereçamento privado (RFC 1918) acessem à Internet. Dessa forma, se a estação 10.10.10.1 necessita acessar um servidor na Internet, então será necessário traduzir o endereço 10.10.10.1 para um endereço publicamente conhecido. Como os principais protocolos de transporte (no caso, TCP e UDP) utilizam o conceito de multiplexação através de portas de origem e destino, então podemos utilizar somente um endereço IP público para traduzir vários endereços privados (NAT masquerade ou NAT Hide), utilizando portas diferentes e armazenando todas estas informações em uma tabela de conexões.

Entretanto, o protocolo ESP (utilizado no IPSEC) não utiliza o mesmo conceito de portas utilizado nos protocolos TCP e UDP e, portanto, não é possível fazer a tradução de endereço e utilizar a informação de portas de origem e destino como forma de multiplexação das conexões. Para que uma conexão VPN funcione quando existe um equipamento fazendo NAT (Hide ou muitos-para-um) entre os pontos que estão estabelecendo a VPN é necessário que haja um mecanismo para garantir que os pacotes serão traduzidos adequadamente, desde a origem até o destino final. Este mecanismo é chamado de NAT Traversal.

De uma forma bem simples, o NAT Traversal primeiramente verifica se os dois equipamentos que estão estabelecendo a conexão possuem suporte para NAT Traversal, em seguida os dois equipamentos devem detectar se existe ou não a tradução de endereços. Por fim, deve-se negociar os parâmetros do protocolo (portas utilizadas para encapsulamento, utilização de cookies, etc) e em seguida iniciar a transmissão de dados utilizando pacotes encapsulados. Todo este processo esta descrito no RFC 3947 - Negotiation of NAT-Traversal in the IKE.

Este recurso pode ser utilizado com conexões VPN do tipo gateway-to-gateway ou client-to-gateway e deve ser verificado na documentação do equipamento se o mesmo suporta NAT Traversal ou UDP Encapsulation (expressão também utilizada por alguns fabricantes).

Object Filler

Existe algum jeito de automatizar a criação de objetos no Check Point SmartDashboard? Sim, existe, mas não é utilizando o SmartDashboard. :-)

O Object Filler é um software escrito por Martin Hoz, funcionário da Check Point, que gera a partir de uma entrada padrão (arquivo com nomes e endereços, ACL de roteadores Cisco ou firewalls PIX, Juniper Netscreen, etc) scripts que podem ser utilizados no DBedit para automatizar uma tarefa que muitos vezes é árdua.

Vale também conferir o Tutorial que explica detalhadamente como funciona o Object Filler e o funcionamento básico do DBedit.

Object Filler/Object Dumper - 02/08/2007

CEF load-sharing

Existem basicamente duas formas de fazer o balanceamento de tráfego utilizando o CEF (Cisco Express Forwarding): per-packet ou per-destination. Enquanto o balanceamento per-packet é utilizado para balancear igualmente dois links, a principal vantagem de balancear utilizando a configuração per-destination é que o tráfego de aplicações sensíveis a jitter (por exemplo Voz sobre IP) não corre o risco de ter alguns de seus pacotes com maior delay do que outros, o que pode acontecer quando o delay de um caminho é maior do que o delay do outro caminho. A solução que promete resolver alguns destes problemas é utilizar o balanceamento per-port, ou seja, é possível distribuir mais igualmente o tráfego entre os caminhos redundantes sem perda de qualidade para aplicações como VoIP.

Em sua configuração padrão, o Cisco IOS com CEF habilitado trabalha com balanceamento por destino (per-destination) para dois caminhos que tenham a mesma métrica. Para habilitar o balanceamento por pacote, temos que entrar com o comando "ip load-sharing per-packet" nas interfaces de destino do caminho redundante; por exemplo, se a rede 10.10.10.0/24 pode ser alcançada pelas interfaces FastEthernet0/0 e Serial0/0, então devemos entrar com o comando nas interfaces:

Cisco(config)# int fa0/0
Cisco(config-if)# ip load-sharing per-packet
Cisco(config-if)# int ser0/0
Cisco(config-if)# ip load-sharing per-packet

Para verificar o resultado destas alterações, podemos utilizar o comando abaixo ou ainda o "show ip cef 10.10.10.1 internal". Para mais detalhes, consultar a documentação oficial da Cisco para troubleshooting de caminhos redundantes utilizando o CEF.

Cisco#show ip cef 10.10.10.1 detail
10.10.10.0/24 version 7920, per-packet sharing
0 packets, 0 bytes
via 10.2.2.2, FastEthernet0/0, 0 dependencies
traffic share 1, current path
next hop 10.2.2.2, FastEthernet0/0
valid adjacency
via 10.1.1.1, Serial0/0, 0 dependencies
traffic share 1
next hop 10.1.1.1, Serial0/0
valid adjacency
0 packets, 0 bytes switched through the prefix
tmstats: external 0 packets, 0 bytes
  internal 0 packets, 0 bytes

A partir da versão 12.4(11)T do IOS, a Cisco incluiu o suporte a Per-port CEF load-sharing, ou seja, a função hash para balanceamento de carga utilizando CEF pode utilizar as informações de número de porta TCP ou UDP (camada 4) para determinar o rota.

Para habilitar o balanceamento per-port, deve-se utilizar o comando:

Cisco(config)# ip cef load-sharing algorithm include-ports source destination

E para verificar o caminho escolhido:

Cisco# show ip cef exact-route 10.0.0.10 src-port 35 192.168.0.2 dest-port 80

Para saber mais detalhes sobre esta nova feature basta consultar a documentação da versão 12.4 T aqui.

Paper: Fast-Flux Service Networks

No último dia 13 deste mês o projeto Honeynet publicou um white-paper com um estudo sobre a utilização de "Fast-Flux Service Networks", uma tecnologia utilizada por criminosos para ocultar suas atividades na Internet. O documento apresenta um detalhamento muito bom da arquitetura single-flux e double-flux, das principais vantagens para os criminosos que se utilizam da mesma e um estudo de caso de como ele acontece no mundo real, além de detalhes de métodos de detecção.

Know Your Enemy: Fast-Flux Service Networks - 15 July, 2007

Cisco PPPoE Client

Pode-se utilizar um link ADSL e um roteador Cisco da série 800 para combinar uma solução de baixo custo para acesso à Internet. Um dos modos de configurar um ambiente deste tipo é com a utilização de um modem ADSL configurado para atuar em modo bridge ou mesmo um roteador que tenha suporte ADSL e utilizar a configuração de bridge-group entre a interface ATM e Ethernet.

Para este exemplo, utilizamos o cenário abaixo com um modem (modo bridge) e um roteador Cisco 831.

Para fazer a configuração do roteador é necessário configurar uma interface dialer para tratar a conexão ADSL, habilitar vpdn e configurar a interface ethernet 0 para trabalhar como PPPoE.

! configuração do vpdn
vpdn enable

! configuração da interface conectada ao modem ADSL
interface Ethernet0
no ip address
no ip proxy-arp
ip virtual-reassembly
pppoe enable
pppoe-client dial-pool-number 1
no cdp enable

interface Dialer1
ip address negotiated
ip virtual-reassembly
encapsulation ppp
dialer pool 1
dialer-group 1
no cdp enable
! para autenticação via PPP chap
ppp chap hostname user@provedor
ppp chap password 7 
! ou para autenticação PPP pap
ppp pap sent-username user@provedor password 7 

! rota default
ip route 0.0.0.0 0.0.0.0 Dialer1

dialer-list 1 protocol ip permit

Vale lembrar que muitas vezes é necessário ajustar o valor do MSS do cabeçalho TCP para que este tipo de conexão funcione adequadamente, como já havia comentado no post "Cisco, DSL, PPPoE e o MTU". Para troubleshooting deste ambiente, fica a sugestão de executar o comando de verificação "show pppoe session all" para verificar se os endereços MAC foram aprendidos pelo Cisco e, caso positivo, verificar com o "debup ppp authentication" o processo de autenticação ADSL.

cisco#sh pppoe session all
Total PPPoE sessions 1

session id: 45316
local MAC address: 0016.c7ee.f8cc, remote MAC address: 0004.3daa.aafb
virtual access interface: Vi1, outgoing interface: Et0
   286832 packets sent, 365434 received
   17806173 bytes sent, 357739263 received

Cisco Replace e Rollback

A partir da versão 12.3(7)T ou 12.2(25)S não é necessário fazer todo o processo de boot para reverter para a configuração que está gravada na startup-config, basta utilizar a feature "Configuration Replace and Configuration Rollback". A idéia é muito simples: se houver algum problema enquanto estivermos aplicando as novas configurações, é possível reverter a configuração para, por exemplo, aquela que está salva na nvram. É possível também salvar várias versões de uma configuração e carregá-las quando for necessário. Primeiramente, vamos ver um exemplo:

cisco# configure terminal
cisco(config)#interface loopback 0
cisco(config-if)#ip address 10.10.10.10 255.255.255.255

Se não foi satisfatória essa alteração, então podemos carregar novamente a configuração que está gravada na startup-config diretamente para a running-config.

cisco#configure replace nvram:startup-config list
This will apply all necessary additions and deletions
to replace the current running configuration with the
contents of the specified configuration file, which is
assumed to be a complete configuration, not a partial
configuration. Enter Y if you are sure you want to proceed. ? [no]: yes
!Pass 1

!List of Commands:
no interface Loopback0
end


Total number of passes: 1
Rollback Done
cisco#

Até agora, nenhuma novidade. No entanto, podemos combinar o configure replace com o archive, ou seja, podemos armazenar várias versões diferentes de configuração e utilizá-las com o configure replace.

cisco(config)#archive
cisco(config-archive)#maximum 5
cisco(config-archive)#path flash:myconfig

Ou seja, agora podemos ter 5 arquivos de backup que serão gravados na memória flash com o prefixo "myconfig".

cisco#archive config

cisco#sh archive
There are currently 2 archive configurations saved.
The next archive file will be named flash:myconfig-2
Archive #  Name
  0
  1       flash:myconfig-1 <- Most Recent        
  2        
  3        
  4        
  5  
(...)

Agora podemos utilizar o comando "archive config" para gravar e "configure replace" para carregar versões de configuração.

cisco#configure replace flash:myconfig-1 list time 120
This will apply all necessary additions and deletions
to replace the current running configuration with the
contents of the specified configuration file, which is
assumed to be a complete configuration, not a partial
configuration. Enter Y if you are sure you want to proceed. ? [no]: yes
!Pass 1

!List of Commands:
no interface Loopback0
end


Total number of passes: 1
Rollback Done

cisco# configure confirm

Neste último exemplo, utilizamos a opção time no comando configure replace para que se não houver a confirmação (configure confirm) então o IOS irá reverter automaticamente para a última configuração antes do replace após transcorridos 2 minutos (120 segundos).

Cisco PIX e TFTP

Apesar de ter uma interface muito parecida com o IOS, a configuração dos firewalls da Cisco (os famosos Cisco PIX) é em alguns casos muito diferente do IOS utilizado nos roteadores. Por exemplo, quando é necessário copiar uma configuração de um firewall para um servidor tftp e restaurar este backup em um outro firewall os comandos "copy runn tftp" e "copy tftp runn" não estão disponíveis no PIX.

Para fazer o backup da configuração atual de um firewall Cisco PIX (neste exemplo na versão 6.3(5)) para um servidor de tftp, devemos utilizar o comando:

pix1# write net 10.10.10.10:arquivo.cfg

Onde 10.10.10.10 é o endereço IP do servidor tftp e arquivo.cfg é o nome do arquivo que será criado com o backup da configuração.

O processo inverso é um pouco menos trivial e, para isso, devemos utilizar o comando configure dentro da opção de configuração:

pix2# configure terminal
pix2(config)# configure net 10.10.10.10:arquivo.cfg

Após entrar com o comando acima a configuração que foi salva no servidor de tftp será carregada no segundo pix.

Kerberos: No default realm defined for Kerberos!

Para evitar a mensagem do título do post ao tentar conectar em algum equipamento utilizando o usuário utilizado pelo Rancid, coloque a seguinte linha no arquivo .telnetrc do usuário:

#su - rancid
$echo "default unset autologin" > ~/.telnetrc

tcpdump

Quando falamos em sniffers de rede - programas que colocam uma interface de rede em modo promíscuo, capturam o tráfego e mostram para o usuário em um formato amigável -, certamente devemos lembrar do tcpdump. Este software permite a utilização de filtros para capturar somente aqueles pacotes que estamos buscando dentre os milhares de pacotes que trafegam por uma ou outra interface de rede. Neste post tentarei apresentar um pouco como é trabalhar com um sniffer. Antes de mais nada é necessário saber os argumentos mais comuns e o formato do comando:

Para capturar o tráfego da interface eth0 (-i) e não resolver o reverso dos endereços IP (-n); opção que ajuda bastante na velocidade da captura. Capturar até 1500 bytes dos pacotes (-s) ao invés dos 68 bytes capturados na opção padrão. Capturar somente 1000 pacotes (-c) e gravar em um arquivo (-w) chamado file.cap, utilizamos o exemplo abaixo.

root@server# tcpdump -i eth0 -n -s 1500 -c 1000 -w file.cap

A opção -r deve ser utilizada posteriormente para ler o arquivo file.cap. Ou seja, a sintaxe padrão do tcpdump é:

root@server# tcpdump [ opções ] [ expressão ]

E é na parte de expressões que estou interessado hoje. Estas expressões são definidas por palavras reservadas e operadores lógicos para selecionar um determinado tráfego de rede. As principais palavras reservadas são:

- Tipo: host, net, port, ...
- Protocolo: ether, ip, tcp, udp, arp, rarp, ...
- Direção: src, dst, src and dst, src or dst, ...
- Operadores lógicos: and, or, not.

Podemos então montar um filtro para selecionar os pacotes com origem na rede 10.10.10.0/24 e com destino o servidor 192.168.0.1 na porta 80.

root@server# tcpdump -ni eth0 'src net 10.10.10.0/24 and dst host 192.168.0.1 and dst port 80'

Se estivermos em busca dos pacotes de início de uma conexão: pacotes com a flag SYN marcada no cabeçalho do TCP, então podemos utilizar a seguinte combinação:

root@server# tcpdump -ni eth0 'tcp[13] == 2'

Ou seja, o tcpdump irá selecionar somente os pacotes que tiverem o valor 2 (decimal) no décimo terceiro byte do cabeçalho TCP. Se lembrarmos das lições de redes de computadores, sabemos que o décimo terceiro byte do cabeçalho TCP é o byte reservado para as flags do protocolo e o valor 2 em decimal é a representação de 00000010 em binário. Lembre-se também da ordem das flags no cabeçalho: os dois primeiros bits são reservados e os seguintes são URG, ACK, PSH, RST, SYN e FIN. Ou seja, somente o penúltimo bit possui o valor 1 para os pacotes que carregam somente a flag SYN.

Este processo pode também ser utilizado para o protocolo ICMP, como no exemplo abaixo. Para mais detalhes sobre os tipos e códigos do protocolo ICMP consultar o documento oficial da IANA.

root@server# tcpdump -ni en1 'icmp[icmptype]==8'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en1, link-type EN10MB (Ethernet), capture size 96 bytes
23:55:33.232659 IP 192.168.0.x > 200.192.y.x: ICMP echo request, id 52993, seq 0, length 64

As possibilidades de combinação são grandes, já que podemos também utilizar operadores lógicos bit-a-bit para selecionar o tráfego, mas este tipo de filtro vou deixar a cargo do leitor pesquisar. Podemos também utilizar estes filtros para fazer assinaturas de ataques e detectar estes ataques somente com a utilização do tcpdump. Existem dois documentos da SANS que auxiliam na utilização do tcpdump para IPv4 e IPv6. Ou ainda a man page oficial do tcpdump.

Cisco, DSL, PPPoE e o MTU

Depois de configurar um roteador Cisco para autenticar-se em um provedor utilizando PPPoE (mais tarde colocarei como fazer isso aqui também) muita gente pode não conseguir navegar "na Internet". A possível, e mais provável, causa desse problema é a limitação do tamanho máximo do MRU (maximum-receive-unit) definido no RFC2516 como 1492 bytes. Como o MTU (maximum transmission unit) dos segmentos ethernet é geralmente configurado para 1500 bytes, um pacote padrão ethernet não irá trafegar no enlace PPPoE, ou seja, entre o CPE (customer premises equipement) e o aggregator (equipamento do provedor que faz a terminação da conexão PPPoE, também conhecido como BRAS - Broadband Remote Access Server). Para mais detalhes da arquitetura do xDSL/PPPoE consultar este documento.

Dessa forma, mesmo que suas requisições consigam atravessar da sua rede interna para a Internet passando pelo seu enlace PPPoE (MTU menor que 1492 bytes) é muito provável que as respostas às suas requisições voltem em pacotes maiores que este tamanho e o equipamento aggregator da sua operadora irá descartar as respostas, montar e enviar pacotes ICMP informando a origem (neste caso o servidor) que os pacotes excederam o tamanho máximo permitido no segmento. Se o administrador do Firewall (antes do servidor) ou o administrador do próprio servidor configurou um bloqueio para todas as mensagens ICMP com destino o servidor, então a conexão não irá funcionar, pois o servidor não saberá que deve ajustar o tamanho dos pacotes para que os mesmos não sejam descartados no seu caminho de volta.

Para contornar este problema nos roteadores Cisco, existe um comando que pode ser utilizado para ajustar o campo MSS (maximum segment size) do cabeçalho TCP, permitindo que o servidor seja informado do tamanho máximo (MTU) das mensagens aceitas para determinado segmento. Para isso, devemos utilizar o comando "ip tcp adjust-mss 1492" na interface interna da rede.

Router(config)# interface fast 0
Router(config-if)# ip address 192.168.0.1 255.255.255.0
Router(config-if)# ip tcp adjust-mss 1452

Fica a lição de como contornar o problema e, principalmente, de como é importante entender cada tipo de mensagem do protocolo ICMP. Para mais detalhes sobre este problema, consulte este documento da Cisco. Mais detalhes também podem ser encontrados no RFC4638 (Accommodating a Maximum Transit Unit/Maximum Receive Unit (MTU/MRU) Greater Than 1492 in the Point-to-Point Protocol over Ethernet (PPPoE)) que mostra uma tentativa de padronizar um mecanismo para diminuir o impacto desta limitação nas novas redes banda larga.

Caos no IPv4

Para quem ainda não está acompanhando a nova onda de debates sobre o futuro do IPv4, o LACNIC lançou um comunicado no dia 20 de junho 2007 no qual estima que os endereços IPv4 (para tráfego da Internet) se esgotarão em cerca de 3 anos. Em resumo, em 2.010 não haverão mais endereços IPv4 disponíveis.

Segue trecho do comunicado:

"Es un hecho que las direcciones IP basadas en la actual versión del protocolo (IPv4) se terminarán en corto plazo, se estima que en la actualidad queda disponible menos del 18% de total de las direcciones IP versión cuatro", dijo el Director Ejecutivo de LACNIC, Raúl Echeberría. Indicó también que las empresas, gobiernos e instituciones deberían tomar previsiones para adoptar la versión seis de dicho protocolo lo antes posible.

"No deseamos crear pánico, pero los recursos de direcciones IP versión cuatro están en camino de terminarse. Por ello recomendamos preparar los más pronto posible las redes regionales para el uso del protocolo de Internet versión seis. Hay aún muchas aspectos sobre los cuales decidir en relación al consumo de las direcciones IPv4 que aún se encuentran sin utilizar. Algunas de las decisiones pueden impactar tanto en darnos más tiempo como en adelantar la fecha de agotamiento de IPv4. LACNIC informará periódicamente a la comunidad para que todos estemos preparados”, agregó Echeberría.

A grande pergunta é como se dará esta migração de IPv4 para IPv6? Quais serão as pressões técnicas, políticas e de mercado para que se implemente de fato o protocolo IPv6? Em quanto estas respostas não aparecem segue um link que demonstra quais aplicativos, sistemas operacionais fabricantes de equipamentos e ISPs que já implementam IPv6:

http://www.ipv6-to-standard.org/

Dica de site: Internet Health Report

Para quem ainda não conhece existe um site na Internet que fornece uma matriz na qual é possível visualizar como está a comunicação (perdas de pacote e tempo de resposta) entre os principais ISPs mundiais.

http://internethealthreport.com/

Exportar usuários do checkpoint

Para conseguir exportar os usuários VPN criados no checkpoint basta executar o comando abaixo.
Ele irá resultar em um arquivo CVS contendo a listagem dos usuários e seus atributos.

/$FWDIR/bin/fwm dbexport -f /path/aquivo.cvs

Configurando scroll em mouse touchpad de notebook no Ubuntu 7.04

No meu Asus W5FM, usando Ubuntu 7.04, adicionei/alterei no /etc/X11/xorg.conf :

Section "InputDevice"
Identifier "Configured Mouse"
Driver "synaptics"
Option "SHMConfig" "on"
Option "CorePointer"
Option "Device" "/dev/psaux"
Option "Protocol" "ImPS/2"
Option "ZAxisMapping" "4 5"
Option "Emulate3Buttons" "true"
EndSection

Reinicie o X (CTRL + ALT + Backspace). No prompt como root:

#apt-get install qsynaptic
#qsynaptic

Configure o mouse utilizando as janelas do qsynaptic ao seu gosto!

Configurando som em um Asus W5FM com Ubuntu 7.04

Para que o som funcione no notebook Asus W5FM, utilizando o Ubuntu 7.04 Feisty Fawn e o Alsa, adicione no /etc/modprobe.d/alsa-base a seguinte linha:

options snd-hda-intel model=3stack

Reinicie o Alsa. Se não funcionar, para que não precise reiniciar, entre com o seguinte comando como root:

# kill $(lsof -t /dev/dsp* /dev/audio* /dev/mixer* /dev/snd/*) ; sudo modprobe -r $(lsmod |grep ^snd |awk '{print $1}') && sudo modprobe snd-hda-codec && sudo modprobe snd-hda-intel model=3stack

Pronto! Quando eu conseguir fazer funcionar a câmera eu posto aqui! Se alguém souber como, poste um comentário. Volte sempre!

---

If you want your sound working in your notebook Asus W5FM, using Ubuntu 7.04 Feisty Fawn and Alsa, add this line on your /etc/modprobe.d/alsa-base :

options snd-hda-intel model=3stack

For no need to reboot, enter this on your prompt as root:

# kill $(lsof -t /dev/dsp* /dev/audio* /dev/mixer* /dev/snd/*) ; sudo modprobe -r $(lsmod |grep ^snd |awk '{print $1}') && sudo modprobe snd-hda-codec && sudo modprobe snd-hda-intel model=3stack

If somebody knows how to do the camera work using this OS, please, post a comment.

Alterando o shell padrão no Nokia IPSO

Para usar o backspace para apagar os "dedos-gordos", ops! os erros quando está utilizando o shell padrão do Nokia IPSO (C shell), é necessário trocar o C shell pelo sh (/bin/sh).

% clish

NokiaIPSO> set user admin shell /bin/sh
NokiaIPSO> save config
NokiaIPSO> exit

Fica também a dica para alterar opções dentro da CLI (clish) do IPSO.

Dynamips Video Tutorial

Josh Horton publicou em seu blog uma série de tutoriais em vídeo de como instalar e configurar o Dynamips. Vale a pena principalmente pelo conceito interessante de passar uma informação através de imagens.

Installation

Basic T1 Configuration

Communication between virtual router and PC loopback interface

VPN Cisco e MTU

O protocolo IP Path MTU Discovery, definido no RFC 1191, permite que um host descubra dinamicamente qual o maior MTU em que ele pode enviar dados sem ter que efetuar a fragmentação dos pacotes (e que por consequência diminui a quantidade de pacotes enviados). Além disso, este algoritmo é útil caso o MTU de um caminho varie, por exemplo devido ao chaveamente para um link secundário de MTU diferente, permitindo assim que os hosts das pontas "negociem" um novo tamanho máximo de pacote.

O padrão para interfaces Ethernet é de 1518 bytes já contando os cabeçalhos de camada 2. No entanto quando se usa um túnel VPN esse MTU diminui devido aos cabeçalhos adicionais de criptografia (este MTU pode variar dependendo do algoritmo utilizado).

Quando um roteador Cisco tenta passar um pacote maior do que o túnel VPN permite ele manda uma mensagem ICMP unreachable para o originador do pacote informando qual o novo MTU. Portanto é importante permitir que o roteador envie as mensagens de ICMP unreachable com o seguinte comando nas interfaces inside e outside do túnel VPN.

conf t
int fas 0/0
ip unreachables
int fas 0/1
ip unreachables

Para descobrir qual o maior MTU permitido em um determinado caminho podem ser utilizados os seguintes comandos:

traceroute -M -I icmp dest_ip_addr

ou

tracepath -n dest_ip_addr

Maiores informações em:

http://www.cisco.com/en/US/products/ps6350/products_configuration_guide_chapter09186a0080435c3e.html#wp1049788

http://www.cisco.com/en/US/products/ps6350/products_configuration_guide_chapter09186a0080435c3e.html#wp1051721

CUIDADO! Esta página esta infectada!

Sim, esta é realmente uma brincadeira de primeiro de abril, mas o título deste post poderia ser verdade. A nova vulnerabilidade dos cursores animados do Windows CVE-2007-0038 (0-day .ANI vulnerability), agora já não tão "zero-day" assim, deve ser cuidadosamente analisada neste início de semana. O Infocon (do ISC) e o Symantec's ThreatCon já foram alterados para um nível de alerta maior devido à esta nova vulnerabilidade - e esta não é história de primeiro de abril.

A Microsoft confirmou esta vulnerabilidade no último dia 29 - ainda sem disponibilizar o patch, no "Microsoft Security Advisory (935423)" - e provocou uma série de notícias sobre uma vulnerabilidade ainda "sem correção". Ok, você está lendo este post pois com certeza já aplicou o patch no seu computador pessoal e em todos os outros que você administra, certo? Ok, vamos lá, a Microsoft promete disponbilizar o patch até o próximo dia 3...

Como o MSIE faz o download e executa automaticamente um arquivo .ani referenciado dentro de uma página HTML esta vulnerabilidade pode ser facilmente explorada somente deixando um arquivo infectado disponível em um servidor e referenciando este arquivo em uma página web - o que abre um leque enorme de possibilidades associadas a cross-site scripting, SQL injection, etc. além da facilidade de propagação através de worms, por exemplo, baseados em mensagens eletrônicas. Para saber se o seu sistema está vulnerável, consulte a página oficial da Microsoft.

Uma análise detalhada de um artefato infectado foi publicada aqui e o Mcafee Avert Lab Blog publicou um vídeo mostrando o que acontece com o Windows Vista após ser comprometido com um arquivo .ani. O CISRT também publicou um anúncio sobre um novo worm que utiliza arquivos infectados com esta vulnerabilidade para comprometer o sistema operacional.

UPDATE [03-abr-2007]: Patch disponibilizado pela Microsoft em através do Windows Update ou http://www.microsoft.com/technet/security/Bulletin/MS07-017.mspx.

UDPATE [04-abr-2007]: Vários usuários estão reportando que após a aplicação do patch ocorreram outros problemas, inclusive a Microsoft já disponibilizou um novo patch para corrigir alguns desses problemas. Mais detalhes na página do ISC - este que está fazendo um excelente trabalho de divulgação de informações sobre esta vulnerabilidade.

Portas para Acesso do Cliente VPN Check Point

Mesmo sendo muito simples instalar e configurar uma conexão VPN client-to-gateway utilizando o SecureClient ou SecuRemote da Checkpoint, podem haver diversos problemas de conexão entre o cliente e o gateway de VPN quando a comunicação passa através de um firewall (ou proxy) que não libera todo o acesso do cliente para o gateway de VPN. Ou seja, é necessário liberar as portas e protocols (do cliente para o gateway):

• TCP 264 (download da topologia)


• UDP 500 (IPSEC and IKE)
  


• IPSEC ESP (protocolo 50)


• IPSEC AH (protocolo 51)


• TCP 500 (se utilizada a opção "IKE over TCP")


• UDP 2746 ou outra porta(*) (se utilizada a opção "UDP encapsulation")

Esta última(*) é definida dentro das propriedades do gateway Checkpoint (SmartDashboard selecionar o gateway dentro de "Network Objects" e depois em "Check Point") na opção "Remote Access" selecionar qual será a porta UDP na opção NAT Traversal.

Ainda para a versão SecureClient, a Check Point recomenda permitir as seguintes portas:

• FW1_scv_keep_alive (UDP port 18233) — SCV keep-alive packets


• FW1_pslogon_NG (TCP port 18231) or (TCP port 65524 for Application Intelligence) — SecureClient's login to Policy Server


• FW1_sds_logon (TCP port 18232) — SecureClient's Software Distribution Server (SDS) download protocol


• tunnel_test (UDP port 18234) — used by Check Point's Tunnel Test application


• RDP (UDP port 259) — Used in MEP's Proprietary Probing (PP) to discover available gateway
  

Estas informações podem ser utilizadas para a versão NG-AI (testado no R55) e para o NGX (R60). Para mais detalhes consultar o documento do SecureKnowledge Check Point aqui.

Linksys e a porta 916

A porta 916/udp poderia ter passado despercebida por muitos, mas não passou para Daniël Niggebrugge. Neste último dia 20/03/2007 ele anunciou na lista Bugtraq que encontrou uma vulnerabilidade no equipamento Linksys WAG200G que permite qualquer pessoa conectada em uma interface WAN ou LAN obter informações tais como modelo do produto, usuário e senha PPPoA, senha para a interface de configuração web, ssid, chave WPA, etc. Daniël disse também que avisou a Linksys há um mês atrás e não houve qualquer manifestação sobre o problema.

A vulnerabilidade funciona através da porta 916/udp. Basta enviar um simples pacote para a porta 916/udp e esperar pelo resultado em um datagrama IP com endereço de destino 255.255.255.255 (broadcast). Os testes que realizei no access point Linksys WRT54GC são:

02:20:01.749708 IP 192.168.0.1.1866 > 192.168.0.10.916: UDP, length 0
02:20:01.766548 IP 192.168.0.10.916 > 255.255.255.255.1866: UDP, length 443

Sim, realmente funciona. Mais informações na mensagem original do Daniël. Aparentemente o problema não tem correção até o momento.

Simulando roteadores Cisco com Dynagen

Apesar de ser somente uma pequena nota sobre um um software de simulação, o post sobre Dynamips é o mais visitado deste blog. Por isso, achei interessante explicar com maiores detalhes o funcionamento do Dynamips e do Dynagen. Para tornar tudo ainda mais fácil, os exemplos que mostrarei abaixo serão todos baseados no dynamips/dynagen para Windows, mas os mesmos funcionam igualmente no Linux (ou até melhor... quem sabe? Mais adiante discutiremos sobre isso também).

Dynamips é um software de código-aberto escrito por Christophe Fillot para simular um roteador 7200 em um PC comum utilizando um processador MIPS. Com este software é possível simular um IOS diretamente no PC - por este motivo o Dynamips necessita de uma imagem do Cisco IOS para funcionar. Atualmente o Dynamips suporta as plataformas 2600, 3600 e 7200 de roteadores Cisco e ainda vários tipos de módulos para estas plataformas.

Para utilizar o Dynamips, por exemplo, para simular uma rede de 4 roteadores interconectados entre si, era necessário mapear em cada instância do Dynamips as interfaces de interconexão utilizando portas UDP. Para facilitar este trabalho de mapeamento Greg Anuzelli desenvolveu um front-end para o Dynamips chamado Dynagen. Com o Dynagen o mapeamento das interconexões é automático: basta definir em um arquivo de configuração qual interface de um roteador conecta-se a outro roteador. Para saber mais detalhes sobre o Dynagen, consulte este tutorial escrito pelo próprio Greg Anuzelli.

Alguns centros especializados em treinamento para as certificações Cisco já disponibilizam laboratórios pré-configurados - ou seja, um arquivo de configuração do Dynagen - para treinamentos e exercícios em um laboratório virtual. Por exemplo, o arquivo do laboratório virtual do Internetwork Expert pode ser pego aqui e do IE Mentor aqui. Estes dois exemplos anteriores foram especialmente desenvolvidos para provas do CCIE.

Desta vez iremos instalar o laboratório do Internetwork Expert. A primeira medida é ter o Dynagen instalado na máquina. Para isso, você deve fazer o download e instalar o Dynagen e a biblioteca libpcap - como estamos no Windows, iremos baixá-la com o nome de Winpcap. Em seguida será necessário pegar a imagem do IOS e descompactá-la com o PKUNZIP ou Winrar (no windows) ou o unzip do Linux. Neste exemplo, iremos utilizar a imagem c3640-is-mz.123-14.T7.bin e descompactá-la no Linux.

$ unzip c3640-is-mz.123-14.T7.bin && mv image.bin c3640-is-mz.123-14.T7.extracted.bin

Coloque a imagem no diretório C:\Program Files\Dynamips\images. Em seguida, você deve rodar o Dynamips com esta imagem (com qualquer configuração de módulos) para descobrir qual é o valor do idle-pc para esta imagem. Para isso, utilizei o comando "C:\Program Files\Dynamips>dynamips.exe -P 3600 images\c3640-is-mz.123-14.T7.extracted.bin" e aguardei o término do processo de boot da imagem. Note que a CPU do seu PC estará constantemente em 100% pois não carregamos o valor do idle-pc no boot da imagem. Para descobrirmos este valor é necessário entrar com a seqüência de break e em seguida pressionar a tecla "i" durante a execução do simulador. No windows a seqüência de break é "Ctrl+ç"e em seguida "i". Pode ser também a combinação "Ctrl+]" e depois "i".

Router>
Please wait while gathering statistics...
Done. Suggested idling PC:
0x605c057c (count=54)
0x605f1cf0 (count=22)
0x605f1d10 (count=46)
0x605f1ed8 (count=32)
0x605f1f3c (count=27)
0x605f2010 (count=69)
0x606a23fc (count=42)
0x606a2478 (count=21)
0x605f2814 (count=23)
0x605f2850 (count=27)
Restart the emulator with "--idle-pc=0x605c057c" (for example)

Agora podemos testar a imagem com algum dos valores que foram descobertos e verificar que a CPU não está mais constantemente em 100%. Esse procedimento é necessário quando precisamos rodar vários roteadores em um mesmo PC e não queremos esperar vários dias para sair do modo exec e entrar no modo de configuração de um dos roteadores...

Agora ajustamos o arquivo com as configurações do laboratório para refletir o nome da imagem e o valor do idle-pc da imagem que acabamos de testar. Temos que editar o arquivo ie.routing.and.switching.topology.4.00.net e atualizar todas as entradas do nome da imagem e idle-pc.

image = C:\Program Files\Dynamips\images\c3640-is-mz.123-14.T7.extracted.bin
idlepc = 0x605c057c

É importante também ter uma forma de conectar na console de cada um dos equipamentos que serão simulados. Para isso a sugestão para este laboratório é criar uma interface de loopback (para saber como fazer no Windows clique aqui) e atribuir o IP 169.254.0.1/16. Temos que descobrir o endereço de hardware desta interface de loopback com o comando "dynamips -e" - algo como {4065B11C-2A6C-4FD2-8204-A12A9A8328A4} - e atualizar este endereço no arquivo de configuração do laboratório para o último roteador - TermServ - que será nosso servidor de console para todos os outros equipamentos.

Para finalizar, iniciamos duas instâncias do dynamips para suportar todo o laboratório:

C:\Program Files\Dynamips>dynamips.exe -H 7200
C:\Program Files\Dynamips>dynamips.exe -H 7201

E depois iniciamos o Dynagen carregando o arquivo de configuração do latoratório.

C:\Program Files\Dynamips>dynagen.exe sample_labs\internetworkexpert\ie.routing.
and.switching.topology.4.00.net

Reading configuration file...


Network successfully started

Dynagen management console for Dynamips

=> list
Name       Type       State      Server          Console
TermServ   3640       stopped    localhost:7201  2000
R1         3640       stopped    localhost:7200  2001
R2         3640       stopped    localhost:7200  2002
R3         3640       stopped    localhost:7200  2003
R4         3640       stopped    localhost:7200  2004
R5         3640       stopped    localhost:7200  2005
R6         3640       stopped    localhost:7200  2006
SW1        3640       stopped    localhost:7200  2007
SW2        3640       stopped    localhost:7201  2008
SW3        3640       stopped    localhost:7201  2009
SW4        3640       stopped    localhost:7201  2010
BB1        3640       stopped    localhost:7201  2011
BB2        3640       stopped    localhost:7201  2012
BB3        3640       stopped    localhost:7201  2013
FRSW       FRSW       n/a        localhost:7201  n/a
=> start TermServ
100-C3600 'TermServ' started
=>

Agora você poderá iniciar cada um dos equipamentos e conectar nos mesmos para testar as mais diferentes configurações. Depois de iniciar o roteador TermServ, pode-se utilizar o telnet para conectar no TermServ e depois na console de cada um dos equipamentos do laboratório.

C:\telnet 169.254.0.2

TermServ>

Agora temos um laboratório virtual de roteadores para testar e simular os mais diferentes ambientes.

O Dynagen pode trabalhar com instâncias do Dynamips rodando em máquinas diferentes, permitindo simular redes de roteadores ainda maiores distribuindo a carga entre máquinas distintas. Se esta for a sua idéia, então é aconselhável a utilização do Linux, já que o Windows não trabalha muito bem com processos que ocupam mais de 2 GB de memória RAM e sabe-se que tem problemas de desempenho depois de uma certa quantidade de roteadores. Mais informações sobre o Dynamips podem ser encontradas no Forum 7200emu.hacki.at ou ainda no blog do Christophe Fillot, autor do Dynamips.

UPDATE (16-fev-2008): Veja também o post sobre o GNS3.

Configurando Interfaces VLAN no FreeBSD

Quando trabalhamos com vlans, podemos segmentar a rede para diminuir o tráfego broadcast compartilhado e segmentar de forma que por exemplo tenhamos uma vlan por serviço/aplicação. A vantagem de ter um Freebsd com interfaces vlans seria, utilizar a mesma interface física para transportar varios tags (vlan id), excluindo a necessidade de uma placa de rede para cada segmento.

Configurando FreeBSD

Primeiramente necessitamos levantar o módulo if_vlan ou para quem queira deixar este suporte nativamente no kernel.

Para habilitar o suporte a vlans sem ter q recompilar o kernel utilizaremos o comando abaixo:

# kldload if_vlan

Não podemos esquecer de adicionar a entrada if_vlan_load=”YES” no arquivo /boot/loader.conf

Caso você queira compilar o suporte nativamente, adicione a entrada abaixo no seu arquivo de configuração e recompile o seu kernel:

device vlan

Depois do suporte a int vlans estar habilitado, vamos começar a configuração no Freebsd.

Vamos utilizar 4 tags para a nossa configuração, 5, 10, 15 e 20, para facilitar vamos associar o tag ao nome da interface vlan, tag 5 (vlan5), tag 10 (vlan10), tag 15 (vlan15), tag 20 (vlan20).

Criando as interfaces:

# ifconfig vlan5 create
# ifconfig vlan10 create
# ifconfig vlan15 create
# ifconfig vlan20 create

Apenas para conferir se as interfaces foram criadas

# ifconfig

A saída deverá ser algo como mostrado abaixo:

vlan5: flags=8002 mtu 1500
ether 00:00:00:00:00:00
vlan: 0 parent interface:

vlan10: flags=8002 mtu 1500
ether 00:00:00:00:00:00
vlan: 0 parent interface:

vlan15: flags=8002 mtu 1500
ether 00:00:00:00:00:00
vlan: 0 parent interface:

vlan20: flags=8002 mtu 1500
ether 00:00:00:00:00:00
vlan: 0 parent interface:

Nossas interfaces ja estão criadas, agora vamos associa-las ao devido tag e a interface física.

OBS: não é necessario a nome da int vlan ter o mesmo tag, por exemplo, pode ser criado a interface vlan0 e associado qualquer tag, criamos a vlan5 associada ao tag 5 para ficar mais fácil de coomprender.

Associando os tags:

# ifconfig vlan5 vlan 5 vlandev em0
# ifconfig vlan10 vlan 10 vlandev em0
# ifconfig vlan15 vlan 15 vlandev em0
# ifconfig vlan20 vlan 20 vlandev em0

Pronto, os tags ja estao devidamente configurados e associados a interface física em0.

Agora, atribua os endereços ips nas interfaces vlans.

# ifconfig vlan5 192.168.5.1 netmask 255.255.255.0 up
# ifconfig vlan10 192.168.10.1 netmask 255.255.255.0 up
# ifconfig vlan15 192.168.15.1 netmask 255.255.255.0 up
# ifconfig vlan20 192.168.20.1 netmask 255.255.255.0 up

A saída do ifconfig ficará como mostrado abaixo:

vlan5: flags=8843 mtu 1500
inet 192.168.5.1 netmask 0xffffff00 broadcast 192.168.5.255
inet6 fe80::203:47ff:fe07:63ff%vlan20 prefixlen 64 scopeid 0xb
ether 00:0a:5e:53:f8:ec
media: Ethernet autoselect (100baseTX )
status: active
vlan: 5 parent interface: em0

vlan10: flags=8843 mtu 1500
inet 192.168.10.1 netmask 0xffffff00 broadcast 192.168.10.255
inet6 fe80::203:47ff:fe07:63ff%vlan20 prefixlen 64 scopeid 0xb
ether 00:0a:5e:53:f8:ec
media: Ethernet autoselect (100baseTX )
status: active
vlan: 10 parent interface: em0

vlan15: flags=8843 mtu 1500
inet 192.168.15.1 netmask 0xffffff00 broadcast 192.168.15.255
inet6 fe80::203:47ff:fe07:63ff%vlan20 prefixlen 64 scopeid 0xb
ether 00:0a:5e:53:f8:ec
media: Ethernet autoselect (100baseTX )
status: active
vlan: 15 parent interface: em0

vlan20: flags=8843 mtu 1500
inet 192.168.20.1 netmask 0xffffff00 broadcast 192.168.20.255
inet6 fe80::203:47ff:fe07:63ff%vlan20 prefixlen 64 scopeid 0xb
ether 00:0a:5e:53:f8:ec
media: Ethernet autoselect (100baseTX )
status: active
vlan: 20 parent interface: em0

Nossas configurações já estão prontas, todas as int vlans configuradas com as tags associadas e com a interface física fxp0 devinida.

Agora vamos colocar nossas configurações no rc.conf para nao perde-las quando o FreeBSD for rebootado.

Adicionar no arquivo /etc/rc.conf as entradas abaixo:

cloned_interfaces="vlan5 vlan10 vlan15 vlan20"
ifconfig_vlan5="inet 192.168.5.1 netmask 255.255.255.0 vlan 5 vlandev em0"
ifconfig_vlan10="inet 192.168.10.1 netmask 255.255.255.0 vlan 10 vlandev em0"
ifconfig_vlan15="inet 192.168.15.1 netmask 255.255.255.0 vlan 15 vlandev em0"
ifconfig_vlan20="inet 192.168.20.1 netmask 255.255.255.0 vlan 20 vlandev em0"

Nossa configuração está concluída no lado do FreeBSD, vou colocar a configuração que deve ser realizada switchs Cisco Catalyst 3750.

Logue no switch com seu usuário e senha, entre em modo enable:

Switch# enable

Defina uma porta onde será conectado o FreeBSD com as interfaces vlans, no nosso exemplo vamos escolher a porta Gi1/0/1.

Entre em como de configuração

Switch# configure terminal
Switch (config)# interface Gi1/0/1

Lembrando que a interface pode variar conforme o modelo do switch.

Switch (config-if)# switchport trunk encapsulation dot1q
Switch (config-if)# switchport mode trunk
Switch (config-if)# switchport trunk allowed vlan 5,10,15,20
Switch (config-if)# description “DESCRIÇÃO DA PORTA”

Com estas configurações na porta estamos deixando trafegar apenas as vlans 5, 10, 15 e 20, caso queira adicionar mais uma vlan no trunk do switch, utilize o comando abaixo:

Switch (config-if)# switchport trunk allowed vlan add 25

Adicionamos a vlan 25 na porta Gi1/0/1 do switch.

Configure o restante das portas do switch em mode access conforme mensionado abaixo:

Switch (config-if)# interface Gi1/0/2
Switch (config-if)# switchport mode access
Switch (config-if)# switchport access vlan 5

Com isso a porta dois consequirá conversar com a interface vlan 5 do FreeBSD através da porta 1 do switch que esta configurada em mode trunk. Faça o mesmo com as outras portas definindo a vlan que deve ser acessada pela porta.

Com isto finalizamos nosso how-to, este tipo de configuração normalmente é utilizado em firewalls, faça um cálculo de tráfego para não ter gargalo físico na placa de rede, se o tráfego for grande em cada vlan utilize uma placa Gigabit de boa qualidade.

Performance em conexões tcp

Um problema que muitos administradores de rede encontram é quando há reclamações de performance em conectividade. Escrevi um programinha para realizar testes de conexões em modo paralelo e sequencial, um programa em C muito simples, pode ser baixado neste link
Basta compilar com suporte a pthread com o comando abaixo:

gcc multiconnect.c -o multiconnect -lpthread


Syntax: ./multiconnect hostname port [connections]
Se não for passado o número de conexões, o default é 100.

Ele mede a performance em microsegundos já converte para segundos.

Simulando um roteador com JunOS

Não é de hoje que sabemos que grande parte da arquitetura dos roteadores da Juniper é totalmente baseada no PC: memória RAM, ROM, CPU, placa-mãe, etc. Também sabe-se que o JunOS - sistema operacional que controla uma parte específica destes roteadores: a routing engine ou RE - é também baseado no sistema operacional FreeBSD. Por isso, sempre houve um certo mito sobre a possibilidade de rodar o JunOS em um PC "caseiro". Esta combinação - PC mais o JunOS - foi gentilmente apelidada de Olive. A principal motivação para instalarmos o Olive - além da natural curiosidade - é o aprendizado e a familiarização com o sistema operacional JunOS.

Em linhas gerais, os passos para instalar o Olive são:

- Instalar o FreeBSD
- Instalar o pacote do JunOS (jinstall)
- Reboot

Existem também algumas dicas e observação importantes que podem ajudar neste teste. Para começar é recomendável instalar o FreeBSD 4.x-mini (testado com a versão 4.4-mini) com a seguinte estrutura de diretórios:

ad0s1a     /       100M
ad0s1b     swap    1G
ad0s1e     /config 12M
ad0s1f     /var    (maior slice, o resto do disco)

Apesar de ser aconselhável utilizar o modelo de particionamento acima, a instalação do pacote jinstall (JunOS) poderá alterar a estrutura de diretórios caso seja necessário. O próximo passo é copiar o pacote do JunOS - que deve ser um arquivo do tipo jinstall-xxx.tgz - para o diretório /var/tmp e iniciar a instalação. Os passos são:

rm /dev/wd0c
ln -s /dev/ad0c /dev/wd0c
mkdir /var/etc
cd /var/etc
touch master.passwd; touch inetd.conf; touch group
cd /var/tmp; pkg_add jinstall-7.0R1.5-domestic-signed.tgz
reboot

Neste momento você poderá ver o Olive rodando em um PC comum. Para conectar-se e iniciar alguma configuração é necessário possuir um cabo de console e utilizar um programa como o Hyper Terminal ou similar. Se você instalou o Olive em uma máquina virtual VMware (FreeBSD), então você pode utilizar o programa VMware Serial Line Gateway para conectar na porta serial sem a necessidade de um cabo serial - a idéia deste programa é criar um gateway para conexão via telnet e traduzir essa conexão para a porta serial do VMware. No caso do VMware, ainda existe uma dica importante: edite o arquivo *.vmx e adicione a linha descrita abaixo, dessa forma o VMware irá simular uma interface de rede Intel que o JunOS/FreeBSD poderá reconhecer.

ethernet0.virtualDev = "e1000"

É importante saber também que o JunOS/Olive é incompatível com a maioria das placas de rede mais comuns. Para saber mais sobre o Olive, versões testadas de JunOS e placas de rede compatíveis basta acessar a página wiki do Olive ou ainda a página de outras pessoas que também já testaram o Olive como o "Sid Smokes" e o Joel Knight.

DNS e os Ataques de Negação de Serviço

Desde a última semana nós temos ouvido falar de ataques de DoS (ou negação de serviço) e de servidores DNS e, por isso, acho interessante observar o que está acontecendo na rede mundial.

Não é de hoje que sabemos da existência de algumas falhas no protocolo de resolução de nomes na Internet (DNS) que permitem a exploração e a amplificação dos ataques de negação de serviço. Por exemplo, a própria escolha de rodar o DNS sobre o UDP (protocolo não orientado a conexão e que pode ser facilmente forjado para enviar falsas requisições) é uma falha que é muito discutida - veja o draft do Frederico Neves (Registro.br) e do João Damas (ISC) no Working Group dnsop do IETF: "Preventing Use of Recursive Nameservers in Reflector Attacks" e o white paper da Verisign intitulado "Anatomy of Recent DNS Reflector Attacks from the Victim and Reflector Point of View".

A principal questão é: o que eu estou fazendo para me proteger? A resposta desta pergunta pode parecer simples, mas não é. Eu comecei a perceber isso quando me deparei com administradores de DNS que nem ao menos sabiam dizer o que é uma "DNS recursivo". Então, vamos lá:

Um servidor de DNS recursivo está configurado para responder a qualquer requisição de DNS independentemente do IP de origem da requisição ou do tipo da requisição. Esta é uma configuração que permite fazer funcionar qualquer servidor DNS em qualquer rede conectada à Internet - e acredito que muitos servidores estejam configurados desta forma.

O problema começa a ocorrer quando alguém resolve atacar o IP 10.10.10.1 (note: somente como exemplo estamos utilizando endereços inválidos). Este atacante envia uma requisição de DNS com IP de origem 10.10.10.1 para um servidor DNS recursivo qualquer e este servidor responde para o IP 10.10.10.1. Multiplique esta resposta pelo número de servidores que respondem requisições recursivas na Internet e você poderá estimar a quantidade de pacotes (teórica) que pode ser gerada para a vítima do ataque. Mais informações técnicas estão disponíveis no site o CERT.br.

No entanto, adotar políticas de segurança pontuais quando o "burburinho" está acontecendo não é a solução de todos os problemas. Por exemplo, como o endereço IP de requisições de DNS pode ser facilmente falsificado é relativamente fácil fazer um ataque utilizando servidores de DNS recursivos configurados para responder consultas recursivas para um grupo restrito de hosts e atacar um host desse grupo restrito, principalmente se existe um grupo grande de servidores DNS recursivos para este grupo de hosts. Por isso é importante implementar políticas de anti-spoofing no perímetro da rede - ou seja, não é permitido tráfego da parte externa para a parte interna da minha rede com endereço de origem de um host interno.

Apesar da possibilidade remota de fazer um ataque que seja suficientemente grande para prejudicar o funcionamente normal de um servidor vítima, o exemplo acima ilustra perfeitamente como a segurança deve ser implementada em diversas camadas quanto possível e que é absolutamente necessário conhecer todos os aspectos do ambiente que queremos proteger.

Para verificar se o servidor de DNS do seu domínio responde consultas recursivas, basta utilizar um das ferramentas publicamente disponíveis neste site. Destaque para o site DNSreport (ou DNSstuff).

Rancid: Ferramenta para Controle de Configuração de Equipamentos de Redes

Disclaimer: É claro que todos nós fazemos backups regulares dos equipamentos que administramos. Também temos uma ferramenta prática e amigável para controlar as alterações de configuração e, até por isso, eu acho que este post não será tão útil...

Rancid - Really Awesome New Cisco confIg Differ - é um programa que pode ser utilizado para realizar backups e controle de versões de configuração de forma simples e rápida e não somente de equipamentos Cisco (como pode parecer pelo nome). Atualmente o Rancid faz backups de equipamentos Cisco, Extreme, Juniper, Nortel Alteon, etc. e pode rodar em FreeBSD, Linux ou MacOS X.

Esta ferramenta é muito utilizada e já foi comentada em pelo menos duas reuniões da NANOG - uma apresentação e um tutorial. Sabe-se que o Rancid é utilizado como ferramente de backup nas empresas: AOL, Global Crossing, MFN, NTT America, Certainty Solutions Inc.

Em linhas gerais o Rancid realiza os seguintes procedimentos:
- Efetua login nos equipamentos listados no arquivo router.db;
- Roda alguns comandos em busca de informações específicas por tipo de equipamento;
- Formata as saídas dos comandos;
- Envia as diferenças para um e-mail;
- Salva as diferenças em uma base para controle de versões (CVS).

O primeiro passo para ter funcionando o Rancid é fazer um instalação: 1) através do código-fonte ou 2) através do ports do FreeBSD. No caso deste exemplo, estamos utilizando a opção 2 (ports do FreeBSD). Existem também algumas depedências que devem ser instaladas para o correto funcionamento, tais como: gcc, make ;-), cvs, perl, expect e diffutils. Eu ainda precisei instalar para este exemplo o cvsweb e viewcvs (todos disponíveis no ports):

cd /usr/ports/net-mgmt/rancid && make install clean
cd /usr/ports/devel/cvsweb && make install clean
cd /usr/ports/devel/viewcvs && make install clean

O primeiro arquivo que deve ser configurado é o rancid.conf - no exemplo, este arquivo está no diretório /usr/local/etc/rancid. Neste arquivo iremos incluir um grupo de equipamentos, configurar o diretório de trabalho do Rancid (onde armazenaremos as informações de backup) e o diretório raíz do CVS e opcionalmente um e-mail para enviar as diferenças de configuração. As opções que utilizaremos são:

BASEDIR=/usr/local/var/rancid; export BASEDIR
CVSROOT=$BASEDIR/CVS; export CVSROOT
LIST_OF_GROUPS="backbone"

Podemos utilizar diversos grupos e, para isso, basta copiar a mesma configuração que iremos fazer para o grupo backbone para os demais.

É extremamente aconselhável que o Rancid rode a partir de um usuário sem privilégios e dedicado para o rancid. Neste exemplo criamos um usuário rancid que será responsável por rodar o Rancid e armazenar as informações de login no arquivo $HOME/.cloginrc.

O arquivo .cloginrc é o arquivo que armazena as informações de controle de acesso para os equipamentos. Este arquivo deve ser criado no diretório home do usuário que irá rodar o Rancid, sempre lembrando que somente o usuário rancid terá permissão para ler e escrever neste arquivo. A sintaxe do arquivo é a seguinte:

$ more /home/rancid/.cloginrc
add password cisco_router
add password cisco_switch
add password extreme_switch
add autoenable extreme_switch 1
add user extreme_switch

Para mais informações sobre a sintaxe deste arquivo, consulte a documentação oficial do cloginrc.

É importante criar a árvore de diretórios para os backups e para o CVS. Para isso devemos executar o script rancid-cvs que está no diretório /usr/local/bin/rancid-cvs. Em nosso exemplo, este script irá criar uma árvore de diretórios para o grupo backbone dentro do diretório $BASEDIR e $CVSROOT (definido no arquivo rancid.conf).

$ cd /usr/local/var/rancid
$ /usr/local/bin/rancid-cvs

Em seguida, é necessário fornecer informações para que o Rancid inicie o backup dos equipamentos e é importante informar quais equipamentos e de que fabricante estes equipamentos são no arquivo router.db. A sintaxe deste arquivo é muito simples e pode ser consultada aqui. O modelo que iremos utilizar é:

$ cd /usr/local/var/rancid/backbone/
$ more router.db
cisco_router:cisco:up
cisco_switch:cat5:up
extreme_switch:extreme:up

É importante notar que os switches Cisco que roda IOS devem ser cadastrados como tipo "cisco". Para que o Rancid conecte corretamente nos equipamentos é necessário que o nome cisco_switch, extreme_switch, etc resolva para um endereço IP; que pode ser por DNS ou através do arquivo /etc/hosts.

Para testar as configurações basta rodar o script rancid-run. Se os arquivos de log (em /usr/local/var/backbone/log) e os arquivos de configuração (em /usr/local/var/backbone/configs) estiverem OK, então basta incluir uma entrada na crontab do usuário rancid para rodar o script periodicamente. Como exemplo, estamos rodando todos os dias às 3:00 horas da manhã:

$ crontab -l
0 3 * * * /usr/local/bin/rancid-run

Se o apache estiver funcionando corretamente, então será possível acessar as configurações através de um página web (utilizando o cvsweb). Basta incluir o caminho para o diretório $CVSROOT (definido no rancid.conf) no arquivo de configuração do cvsweb (/usr/local/etc/cvsweb/cvsweb.conf) conforme o exemplo abaixo e acessar a URL: http://servidorancid/cgi-bin/cvsweb.cgi.

[ snip! ]
@CVSrepositories = (
'local' => ['My CVS Repository', '/usr/local/var/rancid/CVS'],
[ snip!]

Pode-se obter mais informações sobre o Rancid na página oficial dos desenvolvedores.

Solaris Telnet Exploit

Ontem o diário da ISC/SANS apontou uma nova vulnerabilidade no daemon de telnet (in.telnetd) no Solaris 2.10 e 2.11. Aparentemente esta vulnerabilidade não afeta as versões anteriores do Solaris.

Até aí parece-nos uma notícia "normal" em que é encontrada alguma vulnerabilidade supostamente desconhecida e que foi divulgada através da list Full-Disclosure ou Exploits... No entanto, observamos que existe algo diferente com relação a este exploit, ou melhor, não existe exploit, é simples, fácil, e - se é que podemos dizer isso - trivial.

mycomputer$ telnet -l "-fbin" 10.10.10.1
Trying 10.10.10.1...
Connected to 10.10.10.1
Escape character is '^]'.
Last login: Mon Feb 12 11:47:28 from anothercomputer
Sun Microsystems Inc. SunOS 5.10 Generic January 2005
$

Gadi Evrom, na lista Full-Disclosure, aconselhou a Sun Microsystems a fechar no perímetro da rede todo e qualquer tipo de acesso à porta 23 destinado ao /8 alocado para a Sun. Eu acho que este conselho vale para todos. Outra forma de se proteger deste ataque é desabilitar o serviço de telnet no Solaris (cortesia do CAIS-RNP). Mais informações podem ser encontradas no paper 0day was the case that they gave me ou diretamente na página do diário ISC/SANS sobre a vulnerabilidade.

SFP (Gbic)

Abaixo segue uma tabela que referencia os tipos de SFP (Small Form-factor Pluggable) padrão Cisco e suas capacidades de transmissão.

Click na imagem para ampliar

Abaixo, seguem outras refências sobre GBICs (inclusive outros fabricantes):

Juniper

Extreme

Cisco

Testando o tempo de resposta de páginas web

Frequentemente nos deparamos com um problema de lentidão onde é preciso saber onde esta o problema. Resolução de DNS? Tempo de resposta da rede? Tempo de resposta da aplicação?

Uma excelente ferramenta para realizar testes e descobrir onde está o problema é o curl. Ele consegue nos retornar o tempo gasto em cada uma dos seguintes processos: Tempo de resolução de nomes; tempo de conexão tcp (handshake); tempo total de resposta da página (soma dos demais tempo e aplicação).

Abaixo segue um exemplo de utilização do mesmo:

curl -w "NameLookup: %{time_namelookup}\\nTimeConnect: %{time_connect}\\nTimeTotal %{time_total}\\n" -s http://www.google.com.br -o /dev/null

Este comando deve retornar essa resposta:

NameLookup: 0.002
TimeConnect: 0.152
TimeTotal 0.309

Se preciso, pode-se gerar uma lista com os tempos de resposta para ser colocado em uma planilha ou gráfico:

while true;
do
curl -w %{time_namelookup}-%{time_connect}-%{time_total}\\n -s http://www.teste-site.com.br -o /dev/null >> teste_site.txt;
sleep 1;
done

Kernel enxuto no OpenBSD

Uma ferramenta interessante para "enxugar" o seu kernel no OpenBSD é o dmassage, que pode ser baixado em http://www.sentia.org/downloads/dmassage-0.6.tar.gz.

Descompacte o programa:
#cd /root (baixei no diretório do root)
#tar -zxvf dmassage-0.6.tar.gz

Para utilizá-lo, vá para o diretório onde ficam os arquivos do kernel em sua plataforma. Por exemplo:

# cd /usr/src/sys/arch/i386/conf/
# /root/dmassage-0.6/dmassage -s GENERIC > KERNEL

A ferramenta irá analisar os devices carregados através da saída do dmesg e irá comentar no arquivo GENERIC os devices não utilizados. O novo arquivo de kernel estará no arquivo KERNEL, somente com o estritamente necessário.

Após isso, pode continuar o procedimento normal de compilacão e instalacão do seu kernel.

Looking Glass

Looking glass é uma ferramenta que permite efetuar consultas sobre tabelas de roteamento (protocolo BGP) e testes de ping e traceroute. Ela é muito útil para que os administradores de rede possam obter uma visão externa de como estão sendo propagados os anúncios dos seus blocos CIDR na Internet.

A grande maioria dos looking glasses são de acesso gratuito e são implementados através de uma interface web, mas também é possível encontrar quem disponibilize o acesso direto a um roteador (real ou virtual) em que se pode conectar através de telnet. Em ambos os casos os comandos que podem ser efetuados são limitados para evitar problemas de segurança.

Segue a lista de looking glasses que costumo consultar:

Alog - http://lg.alog.com.br/
AMPath - http://routerproxy.grnoc.iu.edu/ampath/
ANSP - http://lg.ansp.br/lgform.cgi
AT&T - telnet://12.0.1.28
Bahialink - http://lg.bahialink.net.br/
BRCentral.net - http://lg.brcentral.net.br/klg.php
CERN - http://lg.cern.ch/ 
Commcorp - https://noc.commcorp.net.br/lg

CTBC - http://lg.ctbc.com.br/lg.php

GlobalCrossing - telnet://route-server.gblx.net
GlobalCrossing - http://www.globalcrossing.com/network/network_looking_glass.aspx

Host.net - telnet://route-server.host.net
Hurricane Electric - http://lg.he.net/
iPivot - http://lg.ipivot.net.br/
iVeloz - http://lg.iveloz.net.br/
Maxiweb - http://lg.maxiweb.com.br/cgi-local/lg.cgi
NetBotanic - http://lg.netbotanic.com.br/lg.php
NTT - http://www.us.ntt.net/support/looking-glass/
PCH - https://prefix.pch.net/applications/lg/

PTTMetro-RJ - telnet://lg.rj.ptt.br
PTTMetro-SP - telnet://lg.sp.ptt.br
RedIRIS - http://www.rediris.es/red/lg/
RNP - https://memoria.rnp.br/ip/lg.php
Savvis - http://as3561lg.savvis.net/lg.html
Seabone - https://gambadilegno.noc.seabone.net/lg/
SUNET - http://stats.sunet.se/looking-glass/lg.cgi
SouthTech Telecom - http://bgp.stech.net.br/lg
Sprint - https://www.sprint.net/lg/lg_start.php
Telefônica TIWS - https://www.globalsolutions.telefonica.com/en/wholesale/looking-glass/
Unifique - http://asn28343.net.br/
Zayo - http://lg.zayo.com/lg.cgi

Links adicionais de sites e operadoras que fornecem o mesmo serviço:

http://www.bgp4.as/looking-glasses
http://www.nanog.org/lookingglass.html
http://www.lookinglass.org/sorted.php


AT&T (SBCGlobal) - telnet://route-server.sbcglobal.net
GVT - https://lg.gvt.net.br
Level3 - http://www.level3.com/LookingGlass/
SimTelecom - http://noc.simtelecom.net.br/cgi-bin/lg.cgi
Telefônica - http://lg.ri.telefonica-data.net/cgi-bin/lg.pl
TIM - http://lg.timbrasil.com.br/executeCommand.tim

(*) Alguns links estão fora. Mantivemos somente para registro histórico.