ART.redundant Firewalls

Rod. SC 401 - Km 01 ParqTec Alfa - GeNESS Florianpolis - SC / Fone: (48) 239- 2280 [email protected]

Alta Disponibilidade de Firewalls em Ambientes CorporativosCassio Brodbeck [email protected] Resumo . Este trabalho demonstra a necessidade de um ambiente de alta disponibilidade para firewalls em empresas que tem seu modelo de negcios ou parte de seus processos voltados para a Internet. Sero apresentados conceitos bsicos de filtragem de pacotes, tipos de firewalls e dificuldades relacionadas para implementao de redundncia nos mesmos. Mais especificamente, aborda os protocolos, softwares e tcnicas envolvidas para a montagem de um firewall tolerante falhas no sistema operacional Linux e OpenBSD. Palavras- chave: alta disponibilidade, firewall , SPOF.

1. Introduo

Um firewall parte fundamental de uma arquitetura de redes de computadores que visa, direta ou indiretamente, controle de acessos nos mais variados nveis da stack TCP/IP. tambm um elemento essencial no mundo da Segurana da Informao. Alm disso, na maioria dos casos o firewall o ponto de comunicao das organizaes com o mundo externo, como a Internet, o que significa que este dispositivo deve estar sempre operando em boas condies. Visto sua importncia estrutural e funcional, irei abordar ao longo do documento solues de software que tem por objetivo diminuir o downtime dos firewalls, aumentando a produtividade das corporaes entre outras coisas.

2. Overview dos tipos de firewalls

Temos disponveis no mercado e na Internet vrios mecanismos que fazem a filtragem de pacotes das mais variadas formas, entretanto,


os conceitos envolvem basicamente 3 tipos de filtragem:

Stateless ou esttica: so as filtragens mais simples e que consomem mais recursos dos dispositivos. Cada pacote analisado de forma independente, sem nenhuma associao com possveis pacotes que j foram processados.

Stateful ou dinmica: so filtragens mais refinadas e que oferecem um desempenho visivelmente melhor do que a filtragem anterior. Nesta filtragem h conhecimento de conexes, cada pacote analisado e associado (ou no) a uma conexo j existente. Este processo permite que os pacotes associados conexes

estabelecidas passem automaticamente, diminuindo o overhead de anlise e ao sobre cada pacote.

Proxy: so filtragens complexas, e portanto mais lentas, que atuam predominantemente nos protocolos de aplicao. A velocidade est relacionada a quantidade de demultiplexao que necessria para anlise em um simples pacote de rede.

Conceitos revistos, vamos dar continuidade ao foco principal deste artigo que envolve a alta disponibilidade, ou redundncia, de firewalls .

3. SPOF - Single Point Of Failure

A idia que gostaramos de ter que os sistemas computacionais no parassem ou no apresentassem problemas que prejudiquem o trabalho de uma empresa no todo. Qualquer corte de comunicao de dados entre o ambiente interno de uma organizao com o ambiente externo implica


especialmente em prejuzos financeiros, seno piores. Ao construir uma estrutura de comunicao de dados devemos estar atentos aos SPOF's, eliminando- os de acordo com as necessidades funcionais das organizaes. SPOF um componente diante de todo o sistema existente que se eventualmente parar, faz com que todo o sistema tambm pare. Os projetos devem prever os SPOF's, mas infelizmente na prtica poucas empresas de fato acabam implementando mecanismos para contorn- los. Podemos eliminar os SPOF's com boas polticas de redundncia, neste caso, redundncia de firewalls .

4. Redundncia em firewalls estticos e dinmicos

As tcnicas de redundncia para firewalls variam de acordo com o tipo de filtragem utilizada. Para entendermos os procedimentos

necessrios para criar firewalls redundantes precisamos antes saber bem como funciona na teoria e prtica a filtragem que est ou vai ser utilizada. Como dito anteriormente, um firewall esttico (tambm chamado sem estado) analisa cada pacote de maneira independente sem fazer nenhuma associao com pacotes j processados. Este tipo de filtragem lento pois requer uma anlise de todas as regras at que uma confira com o pacote em questo. Dessa maneira, quanto maior o nmero de regras, mais lento fica o processo de filtragem. Neste caso, o que precisamos para a redundncia apenas manter, entre dois ou mais equipamentos (desempenhando o papel de firewall ), um endereo IP compartilhado que esteja disponvel todo o tempo. Diversas tcnicas podem ser utilizadas para realizar este


trabalho, desde pequenas solues de garagem at protocolos e softwares consolidados. A redundncia em firewalls dinmicos, por outro lado, algo bem mais complexo, que tem sua origem nos prprios conceitos que envolvem a filtragem stateful . Associar pacotes conexes j existentes um processo totalmente dependente do protocolo em questo. Os estudos mais interessantes envolvem o protocolo TCP (Transmission Control

Protocol )1 , muito embora protocolos no orientados a conexo, como ICMP e UDP, tambm podem se enquadrar na filtragem com estado.

Figura 1 Estabelecimento de uma conexo TCP (three- way handshake ).

O elemento fundamental para um firewall dinmico a tabela de estados. Ela responsvel por manter uma lista com todas conexes ativas, alm de ser fonte de consulta para a filtragem de maneira geral. No processo de filtragem, a tabela de estados consultada primeiro e os pacotes so validados caso pertenam ou se relacionam 1Real Stateful TCP Packet Filtering in IP Filter , http: / / h o me.iae.nl /users/guido / papers/tcp_filtering.ps.gz. Guido van Rooij,


com alguma conexo j estabelecida. Sendo assim, em um ambiente redundante as partes envolvidas devem, alm de compartilhar um endereo IP, tambm manter a tabela de estados sincronizada. A utilizao de firewalls dinmicos proporciona um conjunto de regras mais simples e elegante, onde no h mais preocupao em liberar trfegos bidirecionais, tratar flags em cabealhos e outros detalhes.

4.1 A tabela de estados do Linux e do OpenBSD

A implementao de filtragem dinmica pouco ou at mesmo muito diferenciada entre os sistemas operacionais, especialmente neste caso, onde iremos abordar o Linux e o OpenBSD. Netfilter /iptables o framework disponvel no Linux 2.4 e 2.6 que permite a realizao de filtragem de pacotes (esttica e dinmica), tradues de endereos/portas entre outras coisas. No OpenBSD temos o Packet Filter (mais conhecido pelas iniciais PF) desempenhando as mesmas funes citadas acima, mas com diversas diferenas de implementao. O iptables mantm sua tabela de estados no arquivo /

proc/net /ip_conntrack ; podemos visualiz- la atravs de um simples cat. O arquivo /proc/sys/net /ipv4 /netfilter/ip_conntrack_max

mantm o nmero mximo de conexes simultneas. Este valor calculado de acordo com o total de memria RAM. Em um firewall com 512Mb de RAM, por exemplo, temos o ip_conntrack_max com o valor 32760. Abaixo segue uma entrada na tabela de estados que representa


uma conexo SSH.

tcp 6 431991 ESTABLISHED src=10.1.0.2 dst=10.1.0.4 sport=43078 dport=22 packets=117 bytes=9704 src=10.1.0.4 dst=10.1.0.2 sport=22 dport=43078 packets=73 bytes=8588 [ASSURED] mark=0 use=1

Vamos entender melhor o significado de cada componente nesta entrada:

O protocolo TCP, cujo nmero (veja /etc/protocols ) 6. A entrada na tabela de estado tem 431991 segundos at expirar. Este valor pode ser obtido atravs do arquivo

usr/src/linux /net / ipv4 /netfilter /ip_conntrack_proto_tcp.c.

ESTABLISHED

significa que a conexo est ou foi estabelecida.

Endereos e portas de origem e destino bem como o nmero de pacotes e bytes da conexo que originou a entrada na tabela de estado so representados por src=10.1.0.2 dst=10.1.0.4 sport=43078dport=22 packets=117 bytes=9704.

Endereos e portas de origem e destino bem como o nmero de pacotes e bytes que so esperados como resposta (at ento a conexo marcada como [UNREPLIED]) so representados porsrc=10.1.0.4 bytes=8588. dst=10.1.0.2 sport=22 dport=43078 packets=73

[ASSURED]

garante que a conexo no ser retirada da tabela de

estado mesmo em sobrecarga.

Como podemos perceber, o netfilter/iptables utiliza basicamente dos pares de endereo e porta para identificar uma conexo. Muito embora esse procedimento funcione perfeitamente, no que tende a


segurana somente estes parmetros podem no ser suficientes. Para diminuir o leque de oportunidades para um pacote TCP malicioso atravessar um firewall, interessante que no processo de associao de estados sejam inspecionados o tamanho de janela (window size) e principalmente os nmeros de seqncia (sequence numbers ). Tal mecanismo no est disponvel no netfilter/iptables , a menos que o patch tcp- window- tracking seja aplicado. Maiores detalhes sobre a importncia e implementao das tcnicas por trs do tcp- windowtracking podem ser encontradas em

http:/ / www.iae.nl/users/guido /papers/tcp_filtering.ps.gz . Por outro lado, de uma forma bastante diferenciada, temos a tabela de estados do OpenBSD. O mecanismo de filtragem stateful do PF segue os conceitos apresentados por Guido Rooij em seu artigo Real Stateful TCP Packet Filtering in IP Filter .

vr0 tcp 10.1.0.4:22 {cts_buff.h,ct_sync.h,ct_sync_proto.h,ct_sync_sock.h} File include/linux/netfilter_ipv4/cts_buff.h added to patch ct_sync File include/linux/netfilter_ipv4/ct_sync.h added to patch ct_sync File include/linux/netfilter_ipv4/ct_sync_proto.h added to patch ct_sync File include/linux/netfilter_ipv4/ct_sync_sock.h added to patch ct_sync cbc@core:/tmp/ct_sync/linux-2.6.10$ quilt add net/ipv4/netfilter/\ > {ct_sync_main.c,ct_sync_proto.c,ct_sync_sock.c} File net/ipv4/netfilter/ct_sync_main.c added to patch ct_sync File net/ipv4/netfilter/ct_sync_proto.c added to patch ct_sync File net/ipv4/netfilter/ct_sync_sock.c added to patch ct_sync cbc@core:/tmp/ct_sync/linux-2.6.10$ cp /tmp/ct_sync/netfilter-ha/linux2.6/ct_sync/*.h\ > include/linux/netfilter_ipv4 cbc@core:/tmp/ct_sync/linux-2.6.10$ cp /tmp/ct_sync/netfilter-ha/linux2.6/ct_sync/*.c\ > net/ipv4/netfilter/ cbc@core:/tmp/ct_sync/linux-2.6.10$ quilt refresh Refreshed patch ct_sync.patch

Patches aplicados hora de habilitar as opes referentes ao ct_sync no kernel e fazer o processo de compilao. As opes abaixo


devem

ser

marcadas

sobre

Device packet

drivers/Networking filtering/IP: Netfilter

support /Networking configuration.

options/Network

Connection tracking events Connection tracking state synchronization

6.2.2 Preparando o ambiente para configurao.

O ct_sync corresponde a parte responsvel por sincronizar as tabelas de estado entre os equipamentos envolvidos no grupo.

Devemos utilizar o ucarp para garantir o IP failover . Os conceitos so exatamente os mesmos vistos no tpico 6.1, s a passagem de parmetros que acaba sendo diferenciada. O ucarp tem as seguintes opes:

root@core:~# ucarp --help ucarp 1.1 - Jun 7 2005

--interface= (-i ): bind interface --srcip= (-s ): source (real) IP address of that host --vhid= (-v ): virtual IP identifier (1-255) --pass= (-p ): password --preempt (-P): becomes a master as soon as possible --addr= (-a ): virtual shared IP address --help (-h): summary of command-line options --advbase= (-b ): advertisement frequency --advskew= (-k ): advertisement skew (0-255) --upscript= (-u ): run to become a master --downscript= (-d ): run to become a backup --deadratio= (-r ): ratio to consider a host as dead --shutdown (-z): call shutdown script at exit --daemonize (-B): run in background --facility= (-f): set syslog facility (default=daemon)

Existem 2 (dois) parmetros bastante interessante que so o upscript e downscript . Estes parmetros indicam arquivos que devem


ser executados quando um equipamento vem a ser o master ou slave, respectivamente. Seguindo configurao: a mesma infra- estrutura, temos a seguinte

# Firewall Primrio cbc@core:~$ ip addr list 4: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:e0:7d:72:fd:0c brd ff:ff:ff:ff:ff:ff inet 192.168.7.3/24 brd 192.168.7.255 scope global eth0 5: eth1: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:e0:7d:d4:00:01 brd ff:ff:ff:ff:ff:ff inet 192.168.0.2/24 brd 192.168.0.255 scope global eth1 6: eth2: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:e0:7d:e5:06:1a brd ff:ff:ff:ff:ff:ff inet 10.0.0.1/30 brd 10.0.0.3 scope global eth2

# Definies CARP root@core:~# ucarp -i eth0 -s 192.168.7.3 -v 1 -p foo -a 192.168.7.2 -u /etc/ucarp/up-eth0.sh -d /etc/ucarp/down-eth0.sh -B root@core:~# ucarp -i eth1 -s 192.168.0.2 -v 2 -p bar -a 192.168.0.1 -u /etc/ucarp/up-eth1.sh -d /etc/ucarp/down-eth1.sh -B


# Contedo dos scripts

root@core:~# cat /etc/ucarp/up-eth0.sh #!/bin/sh echo 1 >/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal ip addr add 192.168.7.2/24 dev $1 echo 2 >/proc/sys/net/ipv4/netfilter/ct_sync/state

root@core:~# cat /etc/ucarp/down-eth0.sh #!/bin/sh ip addr del 192.168.7.2/24 dev $1 echo 1 >/proc/sys/net/ipv4/netfilter/ct_sync/state

root@core:~# cat /etc/ucarp/up-eth1.sh #!/bin/sh echo 1 >/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal ip addr add 192.168.0.1/24 dev $1 echo 2 >/proc/sys/net/ipv4/netfilter/ct_sync/state

root@core:~# cat /etc/ucarp/down-eth1.sh #!/bin/sh ip addr del 192.168.0.1/24 dev $1 echo 1 >/proc/sys/net/ipv4/netfilter/ct_sync/state

Para

o

outro

equipamento

s

alterar

as

bases

de

endereamento conforme necessidade, os scripts devem se manter os mesmos. O mecanismo de IP failover j est funcionando, s falta implementar a sincronizao de tabela de estados. Se a opo CONFIG_IP_NF_CONNTRACK_SYNC_MARKED estiver habilitada no kernel somente conexes com pacotes marcados sero replicados. Para isso, ao carregar o mdulo ct_sync a opo cmarkbit deve ser definida com o identificador. A tabela abaixo demonstra os parmetros que podem ser


passados para o ct_sync.

Parmetro syncdev* state id l2drop

Descrio Nome da interface Ethernet que est conectada ao grupo /rede de replicao. Define se deve ser master (2) ou slave (1). Identificador nico. Habilita (1) o recebimento de pacotes nvel 2 (camada de link) somente pela interface de replicao nos slaves. Isso til para garantir que somente pacotes do master vo chegar. Opo desabilitada por padro.

notrack cmarkbit * Parmetro obrigatrio Identificador replicadas. das conexes que devem ser

Aps carregar o mdulo, o ct_sync cria seu prprio diretrio dentro de /proc/sys/net /ipv4 /netfilter . O arquivo principal state, que controla o estado atual da mquina. Se definido como 0, o ct_sync no tem influncia alguma, fica desabilitado. Para tornar slave podemos usar o nmero 1, master 2.

# Firewall Primrio root@core:~# modprobe ct_sync syncdev=eth2 state=2 # Firewall Secundrio root@slave:~# modprobe ct_sync syncdev=eth2 state=1

Feito isso temos um ambiente completo de redundncia para firewalls em Linux. Sinta- se livre para realizar os testes necessrios!

7. Concluso


Muito embora ainda existam alguns obstculos por trs dos protocolos e tecnologias que envolvem a redundncia de firewalls, podemos perceber a simplicidade de implementao das ferramentas em ambientes Linux e OpenBSD. O resultado importncia obtido com a redundncia algo de muita e precisam

a medida

que as corporaes crescem

constantamente estarem conectadas. A redundncia reduz o downtime e aumenta a produo e o faturamento.

8. Bibliografia

[1] http:/ / www.openbsd.org/faq /faq6.html#CARP [2] http:/ / www.countersiege.com/doc/pfsync- carp [3] http:/ / gnumonks.org /projects [4] http:/ / www.netfilter.org [5] http:/ / www.openbsd.org/faq /pf /carp.html [6] http:/ /www.linux.org.uk/~ajh /ols2002_proceedin gs.pdf.gz [7] http:/ / home.iae.nl/users/guido /papers/tcp_filtering.ps.gz

Documents

ART.redundant Firewalls