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.