ART - Redundant Firewalls

Rod. SC 401 - Km 01 ParqTec Alfa - GeNESS Florianpolis - SC / Fone: (48) 239- 2280 contato@ostec.com.
br
Alta Disponibilidade de Firewalls em Ambientes Corporativos

Cassio Brodbeck Caporal
cassio@ostec.com.br 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,
Rod. SC 401 - Km 01 ParqTec Alfa - GeNESS Florianpolis - SC / Fone: (48) 239- 2280 contato@ostec.com.br
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 1
Real 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=43078
dport=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 por
src=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 <- 10.1.0.2:43078
ESTABLISHED:ESTABLISHED [636779211 + 17376]
[2486580302 + 44768](+4146687619) wscale 0 (+4266902570) wscale 2
age 00:48:58, expires in 24:00:00, 1037:675 pkts, 75272:90164 bytes id: 42b9ae1300000003 creatorid: c762bb54
Como podemos perceber, na segunda linha temos as informaes relativas ao tamanho da janela e os nmeros de seqncia da mesma conexo SSH mostrada no formato da tabela de estados do netfilter . Para visualizar a tabela de estados no OpenBSD utilizados o pfctl com o parmetro - s state. O parmetro - vv pode ser usado em conjunto para oferecer maiores informaes. O valor padro de entradas na tabela de estados 10000,
podendo ser alterado atravs da opo set limit states <nmero> .
4.2 Sincronizao de tabelas de estado: Linux e OpenBSD
O Linux ainda no possui uma soluo estvel e padronizada para a sincronizao/replicao da tabela de estados, ao contrrio do OpenBSD, que possui o pfsync. O principal desenvolvedor do Netfilter Team, Harald Welte, est trabalhando em um projeto denominado ct_sync 2 , que uma soluo para sincronizao da tabela de estados entre mltiplos firewalls iptables. Ambas solues utilizam pacotes UDP multicast para
comunicao entre as partes (grupo) envolvidas. Estas mensagens no so criptografadas nem autenticadas, portanto, interessante utilizar IPSec ou ento, uma rede Ethernet exclusiva para esta finalidade. Para apenas dois equipamentos um cabo cross over o suficiente. A topologia ideal seria algo como a figura abaixo.
Figura 2 Arquitetura tradicional para implementao de redundncia.
Antes
de
iniciarmos
processo
de
implementao
de
redundncia de firewalls em Linux e OpenBSD vamos analisar algumas

2 Disponvel em http: / / svn.netfilter.org /cgi - bin/viewcvs.cgi/ trunk / netfilter - ha/.
solues para a redundncia de IP (IP failover ): ucarp , keepalived, heartbeat .
5. O protocolo CARP
Common Address Redundancy Protocol , ou CARP, o protocolo responsvel por criar um ambiente de redundncia entre um atravs do grupo de
compartilhamento
de uma
interface virtual
equipamentos cooperativos. Este protocolo uma melhora do Virtual Router Redundancy Protocol (VRRP), utilizado e desenvolvido pela Cisco. O CARP foi desenvolvido por Ryan McBride aps alguns choques de patente com a Cisco em relao ao VRRP. O CARP um protocolo multicast que agrupa vrios
equipamentos (computadores) fsicos sob um ou mais endereos virtuais. Um dos equipamentos o master e responde a todos os pacotes destinados ao grupo; os slaves ficam apenas na escuta. As mensagens so todas criptografadas. De tempos em tempos (e isso configurvel) o master envia informaes para o grupo atravs do protocolo IP nmero 112. Se o master cair, algum equipamento slave comea a enviar as informaes para o restante do grupo e logo se torna o master . To logo o master retorne a operao, ele automaticamente se torna um slave, a menos que seja configurado para quando retornar, ser sempre o master - til quando existem diferenas de hardware entre os equipamentos do grupo. Para o correto funcionamento precisamos seguir alguns
requisitos: todos os membros do grupo precisam estar na mesma rede fsica, cada interface precisa de um endereo IP real e um
compartilhado/virtual para a redundncia.
5.1 Implementaes do CARP
Muito embora exista um protocolo consolidado para realizar redundncia de endereos IP, solues como o prprio Heartbeat 3 podem ser utilizadas. No Linux temos o keepalived 4 e ucarp 5 que so implementaes do protocolo CARP/VRRP. O primeiro um software mais bem
elaborado e que tem outras finalidades alm da redundncia de IP. J o ucarp, serve nica e exclusivamente para IP failover . Ao contrrio do ucarp, que compatvel com diversos sistemas operacionais, o keepalived de utilizao restrita ao Linux. Este software oferece dois recursos interessantes para o Linux Virtual Server (LVS)6 :
(1) Disponibilidade de servidores reais (real servers) atravs da implementao de health- checks. (2) Disponibilidade do load balancer atravs de mecanismos de IP failover .
Diferentemente, o OpenBSD mantm uma implementao nativa do CARP atravs de um pseudo- device, explorado no prximo captulo.
6. Firewall redundante na prtica
3 4 5 6
http: / / www.linux - ha.org/HeartbeatProgram. http: / / www.keepalived.org. http: / / www.ucarp.org. http: / / www.linuxvirtualserver.org.
A idia por trs da implementao que seja definido um firewall virtual, com endereo IP tambm virtual, que compartilhado por dois ou mais firewalls reais. Somente um equipamento estar fazendo a filtragem de pacotes enquanto os outros ficam apenas na escuta. Se alguma coisa parecer errado com o firewall que est ativo (chamado de master ), um dos outros firewalls (chamados de slaves) assume o endereo IP virtual e passa a efetuar a filtragem. Em paralelo as tabelas de estado so sincronizadas entre os nodos definidos pela infra- estrutura de forma que o usurio no tenha impresso real de que houve o mau funcionamento de um
equipamento.
6.1 Firewall redundante na prtica: OpenBSD
A partir do OpenBSD 3.5 algumas ferramentas foram adicionadas para permitir redundncia de firewalls, em especial o suporte ao CARP para IP failover e pfsync para sincronizao de tabelas de estado. Cada firewall envia suas mensagens (contendo informaes da tabela de estado como insero, remoo ou atualizao) atravs de multicast utilizando o protocolo IP 240 (pfsync). Ao mesmo tempo escutam por mensagens de outros firewalls e as importam para sua tabela de estados. Para assegurar grande volume de pacotes e latncia da rede a implementao do pfsync ainda no dispe de mecanismos segurana. Este ponto crucial e deve ter uma ateno especial pois qualquer pessoa que tenha acesso a camada 2 (link layer) pode realizar ataques alterando as tabelas de estado atravs do envio de mensagens de
multicast pfsync. Por este motivo, interessante manter uma rede Ethernet separada para este tipo de trfego, ou em caso de apenas 2 equipamentos, um cabo cross over suficiente. A figura abaixo um exemplo bsico da implementao dos conceitos vistos at ento. Com base na figura sero abordadas as configuraes necessrias para colocar em funcionamento o ambiente mostrado.
Figura 3 Exemplo bsico de implementao de firewall redundante 7 .
Neste exemplo temos 2 equipamentos e 3 interfaces Ethernet para cada um deles:
A interface externa do firewall primrio dc0 e possui o endereo 192.168.7.3/24; a interface externa do firewall secundrio rl0 e possui o endereo 192.168.7.4 /24.
7 Figura retirada de um documento de Ryan McBride [2] e alterada para o documento em questo.
A interface interna do firewall primrio dc1 e possui endereo 192.168.0.2/24; a interface interna do firewall secundrio rl1 e possui o endereo 192.168.0.3 /24.
A interface de sincronizao em ambos os equipamentos vr0 e possui o endereo 10.0.0.1 /30 no firewall primrio e 10.0.0.2/30 no secundrio . Abaixo segue uma tabela com a configurao de todas as
interfaces em ambos os firewalls:
Firewall Primrio /etc/hostname.dc0 inet 192.168.7.3 255.255.255.0 192.168.7.255 NONE /etc/hostname.dc1 inet 192.168.0.2 255.255.255.0 192.168.0.255 NONE /etc/hostname.vr0 inet 10.0.0.1 255.255.255.252 10.0.0.3 NONE /etc/hostname.carp0 inet 192.168.7.1 255.255.255.0 192.168.7.255 vhid 1 pass fwp1 /etc/hostname.carp1 inet 192.168.0.1 255.255.255.0 192.168.0.255 vhid 2 pass fwp2 /etc/hostname.pfsync0 up syncif vr0
E para o firewall secundrio temos as seguintes configuraes:
Firewall Secundrio /etc/hostname.rl0 inet 192.168.7.4 255.255.255.0 192.168.7.255 NONE /etc/hostname.rl1 inet 192.168.0.1 255.255.255.0 192.168.0.255 NONE /etc/hostname.vr0 inet 10.0.0.2 255.255.255.252 10.0.0.3 NONE /etc/hostname.carp0 inet 192.168.7.2 255.255.255.0 192.168.7.255 vhid 1 pass fwp1 /etc/hostname.carp1 inet 192.168.0.1 255.255.255.0 192.168.0.255 vhid 2 pass fwp2 /etc/hostname.pfsync0 up syncif vr0
Alm disso devemos permitir o trfego carp e pfsync nas interfaces definidas. Ao escrever regras para o firewall , lembre- se de que do ponto de vista do PF todo o trfego vm da interface fsica, mesmo que o pacote tenha como destino endereos CARP.
pass quick on vr0 proto pfsync pass quick on { dc0 dc1 } proto carp keep state # firewall primrio pass quick on { rl0 rl1 } proto carp keep state # firewall secundrio
Para entender melhor as definies feitas acima, vamos analisar as ferramentas de sistema que controlam o funcionamento do CARP: sysctl(8) e ifconfig(8) . A tabela abaixo mostra as opes do sysctl e seus significados.
sysctl(8) net.inet.carp.allow
Descrio Opo habilitada por padro que permite a utilizao do CARP.
sysctl(8) net.inet.carp.arpbalance
Descrio Opo desabilitada por padro; permite load balancing entre hosts virtuais do grupo utilizando ARP. Opo desabilitada por padro, faz log sobre erros CARP. Opo desabilitada por padro; se habilitada permite a definio manual dos equipamentos que devem ter preferncia para ser master .
net.inet.carp.log net.inet.carp.preempt
Para criarmos
a interface carpN devemos conhecer alguns
parmetros que devem ser passados ao ifconfig :
ifconfig(8) advbase e advskew
Descrio Opo para definir a freqncia com que as notificaes devem ser enviadas quando um host o master . advbase pode ser usado para diminuir o trfego de pacotes ou permitir maior latncia antes de um IP take over. O advskew ajuda no controle de qual host deve se tornar o master sem muita demora. Define uma senha para ser utilizada nas notificaes CARP. Define o nmero de identificao do grupo CARP, cada grupo deve ter um. O CARP limitado a 255 grupos. Interface de rede deve fazer parte do grupo CARP.
pass vhid
carpdev
Na configurao mostrada para a figura 3 no h preferncia por um master , ou seja, a posio de master sempre ser apresentada por aquele equipamento que enviar o maior nmero de notificaes. Para definir um equipamento para ser o master sempre que possvel (til quando tem diferenas de hardware) devemos definir
net.inet.carp.preempt=1
em todos
os equipamentos
do grupo
adicionar um valor alto para advskew nos que no devem ser master. Diante definies: do nosso exemplo, deveramos fazer as seguintes
FirewallPrimario# sysctl net.inet.carp.preempt=1 firewallSecundario# sysctl net.inet.carp.preempt=1 firewallSecundario# ifconfig carp0 advskew 100
Para maiores informaes consulte as seguintes pginas de manual: carp(4), ifconfig(8), sysctl(3), sysctl(8), pfsync(4).
6.2 Firewall redundante na prtica: Linux
Como mencionado, o Linux ainda no possui um mecanismo oficial e integrado para a implementao de redundncia. Entretanto, softwares em separado podem ser utilizados para criar um ambiente redundante, exatamente como vimos anteriormente com o OpenBSD. Utilizaremos como base para nosso exemplo a mesma situao mostrada na figura 3 atravs da implementao do ct_sync e o ucarp.
6.2.1 Compilando o ct_sync.
Primeiramente no existe ainda um pacote do ct_sync. Ele est disponvel no endereo http:/ / gnumonks.org /projects atravs do CVS. Existem 2 (duas) implementaes, uma para Linux 2.4 e outra para 2.6. Ambas so bastante limitadas, o ambiente de teste foi utilizando kernel 2.4.26 e 2.6.10.
Para
Linux
2.4:
http:/ /svn.netfilter.org /cgi -
bin/viewcvs.cgi/trunk /netfilter - ha/ .
Para
Linux
2.6:
http:/ /svn.netfilter.org /cgi -
bin/viewcvs.cgi/branches/netfilter - ha/ .
Para o download (utilize o ambiente /tmp /ct_sync):
svn co https://svn.netfilter.org/netfilter/trunk/netfilter-ha svn co https://svn.netfilter.org/netfilter/branches/netfilter-ha
Embora sejam implementaes diferentes os procedimentos para instalao so basicamente os mesmos. Qualquer problema eventual s seguir os procedimentos abordados no arquivo README. Pelo fato de haver muita alterao no core do netfilter o ct_sync possui uma srie de patches que devem ser aplicados. Para facilitar este procedimento uma rvore de patches est disponvel e pode ser gerenciada travs do quilt 8 . O primeiro passo ento instalar o quilt caso ainda no o tenha instalado. Logo aps o cdigo- fonte do kernel deve ser descompactado e diretrio de patches copiado.
cbc@core:/tmp/ct_sync$ tar jxvf linux-2.6.10.tar.bz2 cbc@core:/tmp/ct_sync/linux-2.6.10$ cp -r /tmp/ct_sync/netfilterha/linux-2.6/patches .
Voc pode utilizar o comando quilt unapplied para verificar os patches que ainda no foram aplicados.
8 http: / / savannah.nongnu.org / projects /quilt.
cbc@core:/tmp/ct_sync/linux-2.6.10$ quilt unapplied ct_notifier_pkt.patch pf_packet.patch pf_packet_remove_warning.patch export_ip_conntrack_helpers.patch export_ip_nat_helpers.patch export_ip_conntrack_find.patch export_ip_nat_lock_and_hash.patch export_ip_conntrack_clean_from_lists.patch conntrack_hash_manip.patch conntrack_alloc.patch ct_sync_config_and_makefile.patch
Para aplicar todos os patches utilize o comando quilt push - a.
cbc@core:/tmp/ct_sync/linux-2.6.10$ quilt push -a
A rvore de patches no inclui os arquivos do ct_sync, sendo assim, devemos copi- los para a rvore do kernel depois de aplicar estes patches. Para facilitar, iremos utilizar o quilt .
cbc@core:/tmp/ct_sync/linux-2.6.10$ quilt new ct_sync.patch Patch ct_sync is now on top cbc@core:/tmp/ct_sync/linux-2.6.10$ quilt add include/linux/netfilter_ipv4/\ > {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 <M> 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=<if> (-i <if>): bind interface <if> --srcip=<ip> (-s <ip>): source (real) IP address of that host --vhid=<id> (-v <id>): virtual IP identifier (1-255) --pass=<pass> (-p <pass>): password --preempt (-P): becomes a master as soon as possible --addr=<ip> (-a <ip>): virtual shared IP address --help (-h): summary of command-line options --advbase=<seconds> (-b <seconds>): advertisement frequency --advskew=<skew> (-k <skew>): advertisement skew (0-255) --upscript=<file> (-u <file>): run <file> to become a master --downscript=<file> (-d <file>): run <file> to become a backup --deadratio=<ratio> (-r <ratio>): ratio to consider a host as dead --shutdown (-z): call shutdown script at exit --daemonize (-B): run in background --facility=<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: <BROADCAST,MULTICAST,UP> 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: <BROADCAST,MULTICAST,UP> 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: <BROADCAST,MULTICAST,UP> 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
outro
equipamento
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

ART - Redundant Firewalls

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ART - Redundant Firewalls

Uploaded by

Copyright:

Available Formats

Rod. SC 401 - Km 01 ParqTec Alfa - GeNESS Florianpolis - SC / Fone: (48) 239- 2280 contato@ostec.com.

Alta Disponibilidade de Firewalls em Ambientes Corporativos

2. Overview dos tipos de firewalls

os conceitos envolvem basicamente 3 tipos de filtragem:

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

3. SPOF - Single Point Of Failure

4. Redundncia em firewalls estticos e dinmicos

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

4.1 A tabela de estados do Linux e do OpenBSD

uma conexo SSH.

Vamos entender melhor o significado de cada componente nesta entrada:

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

significa que a conexo est ou foi estabelecida.

garante que a conexo no ser retirada da tabela de

estado mesmo em sobrecarga.

vr0 tcp 10.1.0.4:22 <- 10.1.0.2:43078

ESTABLISHED:ESTABLISHED [636779211 + 17376]

[2486580302 + 44768](+4146687619) wscale 0 (+4266902570) wscale 2

podendo ser alterado atravs da opo set limit states <nmero> .

4.2 Sincronizao de tabelas de estado: Linux e OpenBSD

Figura 2 Arquitetura tradicional para implementao de redundncia.

redundncia de firewalls em Linux e OpenBSD vamos analisar algumas

solues para a redundncia de IP (IP failover ): ucarp , keepalived, heartbeat .

compartilhado/virtual para a redundncia.

5.1 Implementaes do CARP

6. Firewall redundante na prtica

http: / / www.linux - ha.org/HeartbeatProgram. http: / / www.keepalived.org. http: / / www.ucarp.org. http: / / www.linuxvirtualserver.org.

6.1 Firewall redundante na prtica: OpenBSD

Figura 3 Exemplo bsico de implementao de firewall redundante 7 .

Neste exemplo temos 2 equipamentos e 3 interfaces Ethernet para cada um deles:

interfaces em ambos os firewalls:

E para o firewall secundrio temos as seguintes configuraes:

Descrio Opo habilitada por padro que permite a utilizao do CARP.

a interface carpN devemos conhecer alguns

parmetros que devem ser passados ao ifconfig :

ifconfig(8) advbase e advskew

6.2 Firewall redundante na prtica: Linux

6.2.1 Compilando o ct_sync.

http:/ /svn.netfilter.org /cgi -

bin/viewcvs.cgi/trunk /netfilter - ha/ .

http:/ /svn.netfilter.org /cgi -

Para o download (utilize o ambiente /tmp /ct_sync):

svn co https://svn.netfilter.org/netfilter/trunk/netfilter-ha svn co https://svn.netfilter.org/netfilter/branches/netfilter-ha

cbc@core:/tmp/ct_sync$ tar jxvf linux-2.6.10.tar.bz2 cbc@core:/tmp/ct_sync/linux-2.6.10$ cp -r /tmp/ct_sync/netfilterha/linux-2.6/patches .

8 http: / / savannah.nongnu.org / projects /quilt.

Para aplicar todos os patches utilize o comando quilt push - a.

cbc@core:/tmp/ct_sync/linux-2.6.10$ quilt push -a

drivers/Networking filtering/IP: Netfilter

support /Networking configuration.

<*> Connection tracking events <M> Connection tracking state synchronization

6.2.2 Preparando o ambiente para configurao.

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

# Contedo dos scripts

passados para o ct_sync.

Parmetro syncdev* state id l2drop

que as corporaes crescem

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

You might also like