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