Escolar Documentos
Profissional Documentos
Cultura Documentos
IPFW
IPFW
FreeBSD
Se existirem perguntas ou comentrios, por favor, envie-os para walt@erudition.net. A verso mais
recente desse documento vai estar sempre disponvel em www.freebsd-howto.com. Os direitos de
reproduo desse documento so reservados. Verso em portugus desse documento sob responsabilidade
de Patrick Tracanelli (eksffa@free.bsd.com.br) e Maurcio Goto (freebsd-brasil@uol.com.br). A verso
mais recente do mesmo estar sempre disponvel em http://free.bsd.com.br/~eksffa/freebsd/ipfw.php
Sumrio
1. Informacoes gerais sobre a Filtragem de Pacotes de Rede
03
2. Acionando o Ipfirewall(4)
2.1. O /etc/rc.firewall e firewalls com poltica aberta (OPEN)
2.2. Carregando Rulesets (conjunto de regras)
2.2.1. Tipos de Firewall pr-definidos
2.2.2. Tipos de Firewall Personalizado
04
05
06
06
07
08
08
08
10
10
11
12
13
13
13
14
14
15
15
15
16
5. Logs (Logging)
5.1. Propriedades de Logs
5.2. Configuraes de Logs do sistema
5.2.1. Opes do Kernel
5.2.2. Configurando o syslog(8)
5.2.3. Configurao do newsyslog(8) pra fazer rotacionamento de logs (log rotation)
5.3. Configurao de log nas regras
17
17
17
17
18
18
19
21
21
22
25
27
27
27
28
29
30
31
32
2. Acionando o Ipfirewall(4);
O ipfirewall(4) pode ser iniciado de duas formas: voc pode adicionar as opes apropriadas no
seu kernel atravs do seu arquivo de configuraes, e compilar um novo kernel pro seu sistema; ou voc
pode usar o kldload(8) pra carregar dinmicamente o mdulo base do ipfw(8), o ipfw.ko, no kernel. As
duas abordagens funcionam bem pra adicionar um firewall(4) com configuraes bsicas, contudo, a
compilao esttica proporciona, com pouca diferena, uma melhor performance, mas permite ainda que
se adicione opes mais detalhadas de configurao, como por exemplo, a gerao e limitao de logs.
Pra carregar o ipfw de forma dinmica, simplesmente use o comando:
root@eeviac~# kldload ipfw
root@eeviac~#
Pra acionar o ipfirewall(4) de forma esttica, o equivalente seria adicionar a seguinte linha no
arquivo de configuraes do seu kernel:
options IPFIREWALL
Em seguida a compilao e instalao acionaria o ipfirewall(4) esttico no kernel, logo aps a
prxima inicializao do sistema.
Contudo, as coisas no so to simples quanto parecem, se voc simplesmente seguir os passos
descritos acima quando estiver na frente da mquina, vai perceber que existe a necessidade de algumas
opes adicionais pra poder usar a estao. Se voc prestar ateno nos conceitos de poltica de firewall
citados acima (aberto e fechado), vai entender porque o uso do equipamento vai se complicar muito, se
voc no perceber que o firewall usa uma poltica padro fechada. Se voc simplesmente adicionar o
ipfirewall(4) sem nenhuma configurao posterior, todo o trfego de rede vai ser bloqueado, ou seja,
nenhum pacote ser roteado. Isso fatalmente pode se tornar um tormento se voc for adicionar o firewall
remotamente. claro que esse tipo de dor de cabea pode ser evitada, mesmo considerando que no
recomendado acionar o ipfirewall(4) remotamente, tanto de forma esttica quanto dinmica.
Se, de qualquer maneira, voc quiser carregar o ipfirewall(4) de um computador remoto, ento
recomendados que se faa da seguinte forma:
root@eeviac~# kldload ipfw && \
ipfw -q add 65000 allow all from any to any
root@eeviac~#
Assim voc vai automaticamente adicionar uma regra pra permitir todo o trfego da rede, ao
invs de bloquea-lo, evitando assim que voc perca a conexo com a mquina remota. De qualquer
forma, recomendvel que se carregue o ipfirewall(4) dessa maneira em mquinas locais tambm,
especialmente se elas estiverem conectadas em rede, pra no perder uma conexo em andamento.
Acionar o ipfirewall(4) no kernel, de forma esttita em uma mquina remota, contudo, requer um
pouco mais de trabalho. O motivo simples, quando voc termina de instalar um novo kernel, voc
obrigado a rebootar a sua mquina, ai sim, a partir da prxima inicializao ela ir utilizar o novo kernel.
Contudo se voc somente adicionar o ipfirewall(4) no kernel, assim que o sistema estiver no ar, ele no
vai estar roteando os pacotes, ou seja, voc no vai conseguir estabelecer uma conexo remota novamente
com a mquina. Ento antes de inicializar o sistema com um novo kernel voc tem que definir alguma
maneira pra mquina aceitar a sua conexo, pra que assim voc no seja bloqueado pelo seu prprio
firewall.
Pra voc fazer isso, basta adicionar duas linhas no seu rc.conf, uma que vai acionar o firewall na
inicializao da mquina, e outra pra definir o tipo de firewall que vai ser iniciado. No caso firewall do
tipo aberto (OPEN). Ento basta adicionar as seguintes entradas no seu /etc/rc.conf:
firewall_enable="YES"
firewall_type="OPEN"
Existem ainda outros tipos de firewall previamente definidos no /etc/rc.firewall, mas ns vamos
tratar deles posteriormente. Por enquanto vamos comear com uma poltica de firewall aberta (OPEN).
Ainda existe uma alternativa muito boa pra se definir uma poltica aberta como padro pro ipfw(8) no
kernel. Voc pode simplesmente adicionar a seguinte linha no arquivo de configurao do seu kernel:
options IPFIREWALL_DEFAULT_TO_ACCEPT
${fwcmd} add 100 pass all from any to any via lo0
${fwcmd} add 200 deny all from any to 127.0.0.0/8
A varivel ${fwcmd} definida anteriormente no rc.firewall, implicando quando o ipfw(8) vai
ser executado de forma silenciosa (opo -q) ou no. A primeira regra em questo, permite todo trfego
proveniente da interface de loopback (a lo0), e a segunda regra bloqueia todo o trfego direcionado rede
localhost (127.0.0.0). A primeira regra necessria pra permitir comunicao inter-processos locais (local
IPC), e a segunda regra evita que qualquer pacote externo adentre o endereo de host local (localhost
address), que o endereo de loopback, protegendo assim o trfego local. Se essas regras no existirem e
o firewall tiver uma poltica padro fechada, voc vai encontrar problemas na inicializao de alguns
servios, especialmente servios RPC(3), entre outros problemas.
Por isso vale ressaltar a impostncia de se definir o firewall da forma correta, onde o uso do
/etc/rc.firewall via rc.conf altamente recomendvel. Se voc fizer a opo por um script shell que
carregue todas as suas regras e que seja executado sempre que o sistema iniciar, voc deve ficar atento a
essas e outras regras que no devem faltar ao seu firewall.
Em seguida, quando voc define um firewall do tipo "OPEN" (aberto) no rc.conf, o rc.firewall
ativa a seguinte regra no firewall:
${fwcmd} add 65000 pass all from any to any
Essa regra permite que todo trfego externo seja aceito como entrada (com excesso pro
loopback, j que a rede localhost previamente bloqueada) e todo o trfego interno seja aceito como
sada. A mesma funo do IPFIREWALL_DEFAULT_TO_ACCEPT no kernel. Se a poltica aberta
definida no kernel, a regra nmero 65535 vai ser automaticamente carregada como "allow ip from any to
any" no lugar de "deny ip from any to any", posteriormente adicionando a regra nmero 65000. Isso cria
uma redundncia de poltica de firewall aberta. Ento, mais indicado definir o tipo de firewall como
"UNKNOWN"
(desconhecido)
se
voc
adicionou
a
poltica
aberta
(IPFIREWALL_DEFAULT_TO_ACCEPT) no kernel, e no quer permitir mais nenhuma regra do
rc.firewall. Para isso, inclua as seguintes linhas no seu /etc/rc.conf:
firewall_enable="YES"
firewall_type="UNKNOWN"
Se voc quer simplesmente habilitar o firewall para trabalhar algumas regras e ver como o
ipfirewall(4) do FreeBSD funciona, ou ainda, apenas bloquear alguns hosts especficos, e manter as suas
configuraes propcias s suas prprias regras, ento voc pode seguramente pular pra nossa seo 3.
Contudo, se sua inteno usar algum dos conjuntos de regras nativas j existentes no
rc.firewall, ou criar seu prprio conjunto de regras, ento as opes "OPEN" ou "UNKNOWN" no so
suficientes. Ento no pule pra seo 3 (lol).
"CLIENT" - Essa definio de tipo de firewall (firewall_type) permite todo o trfego proveniente
da rede local (por exemplo, uma rede interna atrs de NAT) pra ela mesma. Bloqueia pacotes
fragmentados, permite que mensagens de email, resolues de nomes (DNS) e NTP sejam enviadas pra
dentro e fora da rede, e no permite nenhuma mquina que esteja fora da rede interna iniciar conexes
TCP com mquinas dentro da rede. Se a rede estiver por trs de uma implementao bsica de NAT sem
nenhuma opo de proxie carregada isso j seria impossvel. Esse tipo de firewall funciona com poltica
aberta ou fechada, definida no kernel, ou seja, no faz diferena se voc colocou
IPFIREWALL_DEFAULT_TO_ACCEPT ou IPFIREWALL_DEFAULT_TO_DENY como padro.
"SIMPLE" - Esse tipo de firewall uma contradio. Apesar do nome SIMPLE, ele muito mais
complexo que a definio CLIENT, e requer que o usurio tenha algum conhecimento nos padres RFC
de Internet pra poder entender suas definies de regras de firewall. Essa regra vai evitar spoofing
(tcnica onde uma mquina se faz passar por outra, alterando seu endereamento IP) no permitindo a
entrada de nenhum pacote que tenha um endereo de retorno igual ao endereo de qualquer host dentro da
rede interna. Vai bloquear todos os pacotes endereados como de redes privadas, conforme definido na
RFC 1928, evitando o trfego pra dentro ou fora da rede, e vai bloquear ainda todas as redes noroteaveis, conforme definido no Internet-Drafts da IETF (disponvel em http://www.ietf.org/internetdrafts/draft-manning-dsua-03.txt). Esse tipo de firewall vai permitir trfego de e-mail, de WWW, de
DNS, e NTP, e vai permitir tambm pacotes fragmentados, e em relao s conexes TCP iniciadas por
hosts fora da rede, o firewall no vai apenas bloquear, como na definio CLIENT, vai tambm logar
todas essas tentativas.
"CLOSED" - Tecnicamente essa definio no um conjunto de regras de firewall, porque no
adiciona nenhuma regra. Na verdade, aqui acontece tudo que ns insistimos que voc deve evitar, ou seja,
estabelece uma poltica fechada, negando todo e qualquer trfego da rede (exceto o trfego via lo0 que
ns vimos anteriormente que controlado por padro). Essa definio simplesmente desabilita todos os
servios IP na rede, a no ser que no seu kernel voc tenha adicionado a regra de poltica aberta. Ento,
ajustar o firewall pra CLOSED vai ser necessrio em casos *extremos* onde voc prefere (ainda que
temporariamente) tirar toda a sua rede de funcionamento. Ou seja, no defina como padro no rc.conf.
2.2.2. Tipos de Firewall Personalizado;
Se voc decidiu estabelecer um conjunto de regras customizado, ento recomendvel que voc
especifique um arquivo, ao invs de um dos tipos de firewall abordados acima. A maneira de se
estabelecer esse tipo personalizado de firewall a mesma, utilizando a opo firewall_type no rc.conf,
contudo, basta indicar o caminho (path) pro seu arquivo de regras:
firewall_enable="YES"
firewall_type="/etc/rc.firewall.rules"
Dessa forma voc vai poder definir sua prpria configurao de firewall no arquivo
/etc/rc.firewall.rules, o qual ser carregado sempre que seu firewall for iniciado. Se voc preferir ainda
que seu firewall seja iniciado de forma silenciosa, basta incluir no rc.conf:
firewall_quiet="YES"
O formato do seu conjunto de regras ser apresentado de forma um pouquinho diferente nesse
arquivo, em relao ao que voc encontra no rc.firewall. O motivo simples, o rc.firewall um 'shell
script' sh(1) escrito de forma que possa rodar por si prprio, enquanto o arquivo que define as suas regras
personalizadas esto ali simplesmente para serem processadas pelo ipfw(8). A principal diferena que
voc no vai usar nada correspondente varivel ${fwcmd} usada no rc.firewall. Simplesmente as regras.
Posteriormente, vamos construir um arquivo de regras prprio, e ento vamos ver isso passo-a-passo.
"count" - Todos os pacotes que combinarem com uma regra cuja ao seja "count",
determinar que o ipfirewall(4) incremente o contagem de pacotes, ou seja, a sada de "ipfw show"
indicar mais uma ocorrncia de pacotes nessa regra. Motivos estatsticos bvios. O processamento das
regras do firewall continuam a buscar por outras regras que combinem com os pacotes.
add 1300 count all from any to any
add 1310 count all from 200.230.50.0/24 to 192.168.1.0/24
Essa (primeira) regra incrementa o nmero de vezes que um pacote passou pelo firewall, vindo
de qualquer lugar e indo pra onde quer que seja. J a segunda regra conta quantos pacotes, dentre todos,
estariam sendo enviados da rede 200.230.50.0/24 (origem) pra rede 192.158.1.0/24 (destino). Uma
observao aqui: se o processamento das regras fosse terminado quando um pacote encontra uma regra
cuja ao seja "count", ento, no exemplo acima a regra 1310 no teria serventia alguma.
"skipto <nmero da regra>" - Todos os pacotes que combinem com uma regra cuja ao
seja "skipto <nmero>" vo fazer com que o ipfirewall(4) continue processando esse pacote e buscando
ocorrncia nas regras que sejam de ordem maior ou igual ao <nmero da regra> indicado pela ao.
add 1400 skipto 1800 all from 192.168.1.0/24 to any
Essa regra faria com que todo o trfego vindo da rede 192.168.1.0/24 e indo pra qualquer destino
seja processado pelas regras a partir da regra de nmero 1800
"reject" - Essa ao pouco utilizada atualmente. Quando um pacote combina com uma
regra cuja ao seja "reject", ento o ipfirewall(4) bloqueia esse pacote e responde com uma mensagem
ICMP do tipo "host unreachable", dando a impresso que a mquina se encontra fora da rede. Essa uma
forma no silenciosa de negar o trfego pelo firewall, contudo, assim como a ao "reset", essa ao
tambm aumenta o uso da sua banda de rede.
10
A primeira regra permite todo o trfego de pacotes vindo da rede cujo conjunto de endereos IP
comea em 192.168.0.0 at 129.168.255.255. A regra usa uma mscara (bitmask) pra indicar a
abrangncia do endereamento da rede. A mscara em bits tambm conhecida como bitmask especifica
quantos bits do endereo de rede (192.168.0.0) devem permanecer o mesmo pra cada pacote. Nesse caso,
os primeiros 16 bits dos 32 bits do endereo vo continuar os mesmos. Como os primeiros 16 bits so os
primeiros dois octetos do endereamento da rede, ento todos os endereos cuja origem seja a indicada
nos dois primeiros octetos (ou nos 16 bits iniciais), nesse caso a rede 192.168, sero permitidos por essa
regra.
A segunda regra tem uma funo similar, utilizando as mscaras de rede. A mscara de rede
(netmask) indica quantos bits do endereo de rede deve ser monitorado pelo regra do firewall. No
exemplo acima, a segunda regra (nmero 2100) tem a mscara de rede 255.0.0.0. O primeiro octeto dessa
regra definido como 'bits altos', ou seja, os primeiros 8 bits so 'bits altos', o que indica pro firewall que
apenas os pacotes cujos primeiros 8 bits do endereo da rede devem ser filtrados. Como os primeiros 8
bits da rede igual a 10, ento todos os pacotes cujo endereo de destino seja 10 no primeiro octeto (ou
seja, toda a faixa de 10.0.0.0 at 10.255.255.255) vo combinar com essa regra, e ento sero bloqueados,
como indicado na ao da regra (deny).
O firewall do FreeBSD oferece ainda a possibilidade de inverter a expresso apresentada na
regra com o comando "not". Por exemplo, para que o ipfirewall(4) bloqueie todos os pacotes que no seja
da estao 192.168.0.3:
add 1000 deny all from not 192.168.0.3
3.4.1. Uma introduo Netmask e Bitmask;
O princpio bsico que envolve mscaras de rede e bits de rede (netmask e bitmask) so simples,
mas frequentemente confundidos por pessoas que no tenham muito conhecimento em redes, e ainda
requer um pouco de noo de nmeros binrios. muito mais prtico se ns trabalharmos com endereo
IP em sua forma binria, contudo, a confuso que existe entre os conceitos binrios e decimais costuma
ser decisiva pra algum sem muitos conhecimentos em rede. De qualquer forma, para uma referncia
rpida, a seguinte tabela ilustra que faixa de endereamento IP corresponde a qual bitmask e respectivo
netmask em uma classe C de rede. Alguns breves exemplos de bitmask e netmask adicionais so
ilustradas, denotando algumas definies pra redes maiores.
Bitmask
32
31
30
29
28
27
26
25
24
Netmask
255.255.255.255
255.255.255.254
255.255.255.252
255.255.255.248
255.255.255.240
255.255.255.224
255.255.255.192
255.255.255.128
255.255.255.0
Total de IPs
1
2
4
8
16
32
64
128
256
IPs usveis
1
1
2
6
14
30
62
126
254
22
20
16
12
8
0
255.255.192.0
255.255.128.0
255.255.0.0
255.128.0.0
255.0.0.0
0.0.0.0(todos IPs)
16320
32765
65536
8.388608+e6
256^3
256^ 4
16318
32766
65534
8.388606+e6
(256^3)-2
(256^4)-2
...
Como voc pode ver existe um padro definido. O nmero de endereo total de uma rede sempre
sobra a partir da mscara que lhe foi atribuida, e o nmero total de Ips disponveis (que podem ser usados
por estaes) sempre o total disponvel na rede menos 2 (total 2). O motivo tambm simples, para
cada rede/subrede existem dois endereos IP reservados para o endereo da rede e para o endereo de
broadcast da rede. O ltimo octeto da mscara de rede (netmask) comea com 255 e sempre se
decrementa em valores mltiplos de 2, enquanto o bitmask se decrementa em mltiplos de 1.
Vamos ver, de forma sucinta como usar a tabela acima. Vamos descobrir ento qual a faixa de
IPs que compe uma subrede cujo endereo seja:
11
172.16.100.32/28
O primeiro detalhe ao qual atentamos que o endereo da rede 172.16.100.32, ento sabemos
que a subrede inicia nesse valor, ou seja, o endereo de rede 192.16.100.32. Ento percebemos que o
bitmask do endereo 28. Isso quer dizer que todos os primeiros 28 bits do endereo so 'bits altos', ou
seja, so endereos que no mudam. Portanto, conclumos de forma lgica que temos apenas 4 bits
ajustados como 'bits baixos', j que um endereo completo de rede tem 32 bits, e 28 so altos (conforme
indicado pela bitmask) subtraindo 28 de 32 restam-nos 4 bits (os bits baixos). Sabemos agora que existem
apenas 2 valores possveis para cada bit, j que o endereamento no decimal binrio. Ento elevamos
dois (possibilidades binrias) quatro (bits): 2^4. Agora sim j temos o nmero de estaes que aquele
bitmask est indicando: 2^4 = 16.
Agora basta somar: 172.16.100.32 + 16 = 172.16.100.48, portanto a faixa de endereamento IP
varia de 172.16.100.32 at 172.16.100.48; Se olharmos na tabela apresentada cima, veramos que 16
endereos IP corresponde a um bitmask de 28, que o nosso caso. Dessa forma poderamos ter evitado
todo esse clculo matemtico para encontrarmos o valor exato. Mas, vale lembrar que, nem sempre essa
tabela vai estar disponvel pra voc consultar, a menos que voc a imprima e ande com ela na carteira,
portanto muito mais valioso aprender como o endereamento funciona e aplicar os clculos necessrios.
Aprenda uma vez e use sempre.
3.4.2. Especificando Portas e Faixas de Portas;
Voc pode tambm controlar o trfego de conexes baseando-se em filtragem de portas. Isso
possibilita que voc permita ou negue acesso a um servio em especfico ao invs de controlar o trfego
das estaes todas. A definio das portas em uma regra de firewall com ipfw(8) feita aps a declarao
do endereo de origem ou do endereo de destino, simplesmente definindo a porta aps o endereo. Uma
faixa de portas pode ser especificada com um hfen, podem ser separadas por vrgula, ou ainda, em casos
mais elaborados, pode-se usar um netmask pra definir a faixa de portas. importante lembrar que voc
no pode definir "all" como protocolo na regra que especifica portas, porque nem todos os protocolos
trabalham com portas.
add 1000 allow tcp from any to 172.16.0.5 25
add 1100 allow tcp from any to 172.16.0.5 1021-1023
add 1200 allow tcp from any to 172.16.0.5 21,22,23
add 1300 deny udp from any to 192.168.0.5 1024:8
Na primeira regra, todos os pacotes TCP cujo destino a porta 25 da estao 172.16.0.5 so
permitidos pelo firewall. Na segunda regra todas as conexes TCP cujo destino seja qualquer porta da
faixa 1021 at 1023 da estao 172.16.0.5 tambm so permitidas pelo ipfirewall(4). Na terceira regra,
todos os pacotes TCP destinados s portas 21, 22 ou 23 na estao 172.16.0.5 permitida. E, finalmente
na quarta regra, todos os pacotes UDP destinados pra faixa de portas de 1024 1028 na estao
172.16.0.5 so bloqueados. A apresentao da faixa de portas na ltima regra interessante, porque faz
uso de uma netmask pra declarar a mesma. Mas a matemtica tambm bem simples. Como agora
estamos tratando de Bitmask pra porta 1024, o valor pra ela 10 bits, e como a mscara indica 8 bits,
tiramos 8 possibilidades de 10, restando-nos apenas 2 bits. Como o valor de cada bit binrio, elevamos
os bits disponveis (2) aos valores possveis (binrio = 2): 2^2, ento temos 4 portas que compe a faixa
de endereamento da porta 1024, ou seja, de 1024 at 1024+4 = 1024 at1028.
O uso de mscaras para definio de faixas de portas so raramente usadas, mas so bem mais
interessantes do que o uso de bitmask ou netmask pra endereos IP, j que o nmero de bits de uma porta
varia dependendo da porta em questo. Por isso o uso de hfen recomendado pra se definir uma faixa de
portas, e vrgulas quando se deseja definir vrias portas em uma mesma regra. Mas a declarao de
mscaras para as portas indica que o firewall foi construdo por algum que domina completamente as
definies de endereamento de redes, e esttitamente mais proveitoso.
12
4.1. A ao "unreach";
Primeiramente, vamos introduzir uma nova "ao":
"unreach <cdigo>" - Qualquer pacote que combine com uma regra cuja ao seja
"unreach", ser respondido com um cdigo 'ICMP unreach' (cdigo ICMP de indisponibilidade), e
posteriormente a leitra do conjunto de regras ser terminada. As possibilidades de cdigos pro 'ICMP
unreach' pode ser indicada por nmero ou por nome. Segue agora uma breve lista de 'ICMP unreach
codes' (os cdigos em questo) e seus nomes correspondentes. Se voc no sabe onde esses cdigos so
utilizados, no tem porque voc tentar usa-los:
net 0
net-prohib 9
host 1
host-prohib 10
protocol 2
tosnet 11
port 3
toshost 12
needfrag 4
filter-prohib 13
srcfail 5
host-precedence 14
net-unknown 6 precedence-cutoff 15
host-unknown 7
isolated 8
13
add 1200 allow all from any to any out via any
Voc vai notar que, quando voc listar as regras de firewall, as entradas que estiverem usando
"in" ou "out" combinadas com "via", no apresentaro a utilizao do "via" mas apresentar a citao
"recv" ou "xmit", dependendo da definio de um "in" ou um "out" respectivamente. Veja s:
root@eeviac~# ipfw add 7000 allow all from any to any out via xl0
root@eeviac~# ipfw list | grep 7000
07000 allow ip from any to any out xmit xl0
root@eeviac~#
Portanto, voc pode usar "recv" ou "xmit" no lugar de "via" quando voc for criar alguma regra
que faa uso de "in" e "out", contudo isso no preciso, o ipfirewall(4) distingui se a interface est
recebendo o transmitindo o dado, e, alm do que, essa definio pode confundir usurios no experientes.
No geral, essas opes oferecem muito mais controle sobre o trfego da rede em um sistema de
interfaces mltiplas, e qualquer outro sistema em geral, visto que elas permitem a filtragem de pacotes
especficos vindo para o firewall, saindo por ele, e se deslocando atravs de uma interface especificada.
14
pelo firewall, e a regra seguinte bloqueia todos os pacotes icmp do tipo 8 de entrarem. Em resumo,
permite que qualquer cliente faa um pedido de echo pra fora, e permite a entrada da resposta pra dentro
do firewall, e no permite que ningum de fora faa um pedido de echo pra dentro do firewall, ou seja,
todomundo protegido pelo firewall pode pingar qualquer estao externa, mas ningum de fora pode
pingar dentro. Naturalmente essas opes s podem ser definidas quando o protocolo da regra for "icmp".
4.3.2. tcpflags, setup & established;
"tcpflags <flag>" - Essa opo filtra qualquer pacote TCP cujo cabealho contenha alguma das
flags (opes) identificadas. Uma definio inversa tambm pode ser utilizada se colocarmos uma '!'
(exclamao) antes da <flag>, dessa forma filtrando todos os pacotes TCP que no possuam a <flag> em
questo. Veja as opes de 'flags':
fin - Request for connexion termination (pedido de finalizao da conexo)
syn - Request for connexion initiation (pedido de inicializao da conexo)
rst - Reset Connexion (Redefinio da Conexo)
psh - Push Flag (opo Push)
ack - Acknowledgement (conhecimento, concordncia com a conexo)
urg - Indicate Urgent OOB data (indica um OOB de dados urgentes)
A <flag> SYN a mais interessante, visto que ela enviada quando uma conexo TCP
iniciada. Por ser to importante, existe inclusive uma opo separada do ipfw(8) dedicada especialmente
pra definir pacotes TCP cujo cabealho tenha a flag SYN ajustada. Essa opo se chama "setup". claro
que s podemos trabalhar com a opo "setup" quando o protocolo indicado o "tcp".
"setup" - Qualquer regra contendo essa opo vai filtrar todos os pacotes TCP cujo cabealho
indique a flag SYN ajustada. Dessa forma, se quizermos simplesmente negar todos os pacotes TCP que
estiverem entrando no firewall com o cabealho SYN definido, temos duas opes:
add deny tcp from any to any in tcpflags syn
OU SIMPLESMENTE:
add deny tcp from any to any in setup
Em cada uma dessas regras, a mesma ao tomada: todos os pacotes TCP SYN vindos de
qualquer (any) origem para qualquer (any) destino sero negados. Vale a pena ilustrarmos a necessidade
do protocolo ser "tcp" quando trabalharmos essas regras.
"established" - Exatamente como existe uma opo especial que identifica um pedido de
inicializao de conexo TCP ("setup"), existe tambm uma opo que identifica quando uma conexo j
est estabelecida, ou seja, ja foi iniciada. Pela grande importncia de facilitar o controle de conexes
TCP, as opes "established" e "setup" foram disponibilizadas, dessa forma oferecendo facilidade na
criao de regras. Utilizando estas opes (ou mesmo suas definies nativas correspondentes s
"tcpflags") podemos ter inicialmente um controle de conexes TCP mais simples. Essa a base de
implementaes "stateful" de um firewall. Vamos trabalhar com elas de forma mais detalhada depois.
4.3.3. ipoptions;
"ipoptions <flag>" - Finalmente podemos trabalhar com alguns pacotes IP especficos. A <flag>
que define um tipo de pacote IP nomeada SSRR (para: Strict Source Route), LSRR (para: Loose Source
Route), RR (para: Record Packet Route), e TS (para: Timestamp). Se voc no sabe pra que serve cada
uma dessas flags, ento no haver necessidade de construir regras que faam uso delas.
15
enviados. Dito isso, podemos facilmente definir uma regra pra negar todos os pacotes fragmentados que
estiverem entrando na rede:
add deny all from any to any in frag
16
5. Logs (Logging);
5.1. Propriedades de Logs;
As vantagens de manter os logs do firewall ativo so bvias. A possibilidade de verificar
posteriormente quais conexes foram negadas, de que endereos elas vieram, pra que rede ou estao elas
estavam indo, se o contedo dos pacotes eram fragmentados (indicantivo de muitos ataques de negao
de servio DoS), enfim, possibilita saber onde as conexes esto sendo feitas, por quem e quando. Em
especial, os logs de firewall so importantes pra rastrear crackers ou pessoas m intencionadas.
Mas logar tambm tem o seu lado negativo, se voc no for cuidadoso. Dependendo do tipo de
dado que voc est logando voc pode se perder com a abundncia de mensagens, e tambm utilizar
muito espao em disco pros arquivos de logs. Ataques de negao de servio que tendem a sobrecarregar
discos rgidos um dos tipos mais antigos de atividade m intencionada, e por incrvel que parea ainda
sinnimo de perigo pra administradores imprudentes. Por isso a importncia de se definir que tipos de
regras sero logadas. Normalmente logar pacotes permitidos de servios pblicos (como WWW) no
uma boa india, visto que o prprio servio (servidor WWW) tambm mantm logs das atividades de
acesso, e a frequncia de pacotes em um servio como esse muito grande.
Por outro lado, o que a maioria dos novos administradores que experimentam quando eles
habilitam o ipfirewall(4) pra logar, o seu terminal abarrotado com mensagens sobre a atividade de
pacotes. Esse pequeno inconveniente o resultado da combinao de:
- estar logando regras que combinam com pacotes muito frequentes;
- no ter desabilitado logs pro console e pros terminais de root (pssima idia);
- no estar controlando limite de logs com o IPFIREWALL_VERBOSE_LIMIT;
17
18
Pra se ter uma boa noo de todas as configuraes possveis do newsyslog.conf(5) recomendado que
voc leia a pgina de manual (man newsyslog.conf) do arquivo. Essa uma poderosa ferramenta de logs,
mas no tem porque ns explicarmos ela aqui, isso tarefa pra um captumo sobre administrao do
sistema FreeBSD, pro nosso caso de Firewall especfico a seguinte entrada deve ser o bastante:
/var/log/ipfw/ipfw.log 600 10 * $W0D2 Z
Essa linha pode ser adicionada no final do arquivo newsyslog.conf(5). A primeira entrada um
tanto quanto bvia, ela indica qual arquivo vai ser rotacionado. A segunda indica os bits de permisses
pros arquivos rotacionados. A terceira parte o nmero de arquivo de logs que se deseja manter
rotacionando at que o mais antigo seja apagado. O seguinte o tamanho do arquivo quando ele deve ser
rotacionado, no estamos usando essa opo. A quintar parte quando (tempo) ns devemos rotacionar o
arquivo, e finalmente a ltima opo, uma opo especial. Como voc j deve ter concludo, rotao de
logs so definidas por dois critrios: tamanho ou data. No nosso caso, ns indicamos que queremos que o
arquivo de log seja rotacionado s duas da manh de todo domingo, no importando o tamanho do
arquivo de log. Depois definimos (a ltima opo especial, "Z") que o arquivo deve ser comprimido com
gzip(1) sempre que rotacionar, e definimos que vamos manter um histrico arquivado de 10 semanas. Se
voc deseja manter seus logs por mais que 10 semanas basta alterar o valor 10 pra qualquer um que voc
queira. Ou o ideal, criar uma rotina que faa backup em uma mquina separada (um LogHost) a cada 10
semanas, ou ento gravar seus Logs em CD ou qualquer outra mdia barata e de grande capacidade
quando for necessrio.
Uma vez configurado, o newsyslog.conf(5) vai cuidar do rotacionamento dos logs do
ipfirewall(4). O newsyslog.conf(5) ativado pelo cron(8) do FreeBSD, e por isso no precisa de um
Daemon rodando, consequentemente voc no tem que reiniciar nenhum processo. Voc pode criar seu
prprio script pra rotacionar logs ou usar de terceiros, com tanto que voc confie. De qualquer forma
bom decidir uma maneira de controlar o crescimento dos logs dentro do seu sistema. Lembre-se, no
existe nada que o cron(8) e um script no possa fazer nesse caso.
19
- Nmero da Regra
- Ao
- Endereos IP do Destino & Origem
- Portas de Origem & Destino
- Direo do Fluxo
- A Device onde o trfego aconteceu.
Por definio, uma regra de firewall sua, quando logada, deve parecer com o seguinte:
Oct 09 18:59:31 SuaMaquina /kernel: ipfw: 65000 Deny TCP 172.16.0.1:62307
192.168.0.1:23 in via xl0
20
21
para aqueles pacotes. Se, por outro lado algum pacote no fizer parte de uma conexo iniciada, a regra
1000 no ser assumida, e ento a verificao passa pra regra seguinte. Na regra nmero 2000, se o
pacote for do tipo TCP SYN, e for destinado porta 22 (servio SSH), a regra vai permitir que ele seja
roteado. Nesse caso, pacotes TCP SYN iniciam uma conexo TCP, por isso a importncia de deixa-los
passar. Os pacotes subsequentes relacionados ao servio SSH sero permitidos pela regra 1000, j que
eles faro parte de uma conexo j estabelecida. Voc pode experimentar uma configurao parecida
usando 'stateless':
add 1000 allow tcp from any to any out
add 2000 allow tcp from any to any 22 in
Nesse exemplo, todos os pacotes saindo pelo firewall, vindos de qualquer fonte pra qualquer
destino sero permitidos, e todos os pacotes entrando pela porta 22 tambm sero permitidos. Nesse caso
voc vai perceber que as regras no ficam monitorando os pacotes TCP pra verificarem de que tipo eles
so, se so de inicializao de uma conexo ou de uma conexo j estabelecida, e em contra-partida
permitem que todos os pacotes TCP saiam pelo firewall ou entrem pela porta 22, sem verificar que
pacotes so esses.
Essa a essncia de um firewall do tipo 'stateful' utilizando "setup" e "stablished": Deixa passar
pedidos de inicializao de conexes de um servio (porta) especfico, e depois da conexo estar
estabelecidade permite que todo o trfego funcione normalmente.
Vamos dar uma olhada em um exemplo memos simples, que envolve conexes ssh, email, FTP e
DNS pra rede 172.16.0.0/27:
add 1000 allow tcp from any to any established
add 2000 allow tcp from any to 172.16.0.0/27 21,22,25 setup
add 3000 allow udp from 172.16.0.0/27 to any 53
add 3100 allow udp from any 53 to 172.16.0.0/27
Nesse exemplo, o pedido de inicio de conexo (usando "setup") permitido pras portas 21, 22,
25 (FTP, SSH e SMTP respectivamente) quando os pacotes so destinados rede 172.16.0.0.
Consequentemente todas as conexes TCP estabelecidas sero permitidas na regra anterior. As regras
3000 e 3100 permitem pacotes UDP pra porta 53 de outros hosts, e permite pacotes UDP vindos da porta
53 de qualquer lugar entrarem pelo firewall. Essas duas ltimas regras so 'stateless'. A porta 53 a porta
onde o servio de nomes (DNS) roda. A regra 1000 deve ser "from any to any" porque os pacotes TCP de
conexes j estabelecidas devem ser permitidas vindo de qualquer origem pra qualquer destino. Lembrese sempre que existe o fluxo em duas direos, os pacotes vindos de algum lugar e as suas respostas pra
outro lugar.
Vamos analizar um caso especial: FTP. Se voc fosse fazer um firewall cujas regras fossem
exclusivamente 'stateless', voc teria que manter todas as portas entre a 1024 e a 65000 abertas. O motivo
simples, o protocolo FTP um protocolo revoltadinho que estabelece suas conexes em qualquer porta
no reservada, ou seja qualquer porta acima da 1024. Uma soluo no muito prtica liberar as portas
21 e 22 de forma 'stateless' e forar seus clientes FTP a estabelecerem conexes exclusivamente nopassivas (FTP Modo Passivo). O problema que nem todos os seus clientes (como os que usam Windows
por exemplo) tem muita noo de FTP a ponto de coloca-lo em modo np-passivo, por mais simples que
isso seja. Nesse caso, portanto, permitimos a inicializao de uma conexo na porta 21 (onde todas as
requisies FTP iniciam) e posteriormente permitimos o roteamento de pacotes pertencentes essa
conexo por qualquer porta (utilizando "stablished"). Essa a forma mais eficiente de se controlar FTP
via firewall, e essa prtica pode ser adotada pra outros servios que tenham comportamente similar a esse.
22
certa forma um conjunto de regras monitora no somente o incio de uma conexo, mas tambm quando
essa conexo terminada, e ajusta suas aes de acordo a configurao utilizada.
Uma opo e um comando so utilizados pra controlar esse comportamente 'stateful' avanado:
"keep-state" Quando um pacote combinado com uma regra que tenha essa opo
ajustada, ento uma regra dinmica iniciada.
"check-state" - Esse comando define que a verificao das regras pelo firewall vai
primeiro checar as regras dinmicas. Se no existir uma regra com esse comando em todo o conjunto de
regras do seu firewall, ai as regras dinmicas sero verificadas no momento em que a opo "keep-state"
for definida. Se uma regra com esse comando combinar com um pacote, a verificao das regras
terminada, do contrrio a verificao continua.
Vamos ento voltar ao nosso exemplo anterior, onde tnhamos regras destinadas permitir
apenas conexes SSH, mas dessa vez vamos usar regras mais avanadas de 'stateful':
add 1000 check-state
add 2000 allow tcp from any to any 22 in setup keep-state
S lembrando, essa regra presume que a poltica do seu firewall seja fechada. Nas regras acina, a
primeira regra faz com que o ipfirewall(4) verifique as regras dinmicas. Se o pacote no pertence a
nenhuma conexo j estabelecida (ou seja, no fazem parte de nenhuma regra dinmica) ento a
verificao continua na regra 2000, onde, se o pacote for do tipo TCP SYN entrando pela porta 22 (SSH),
a a funo "keep-state" ordena a criao de uma regra dinmica, que ser sempre verificada na
constatao da regra 1000. Todos os outros pacotes seriam bloqueados pela sua regra padro de firewall
fechado.
Bom, ns j havamos trabalhado com regras desse tipo utilizando as outras funes de 'stateful'
e tambm utilizando 'stateless'. Agora, essa nossa nova abordagem, utilizando a opo "keep-state" e o
comando "check-state" proporciona algumas vantagens sobre as outras configuraes de firewall. Antes,
a opo "stablished" permitia a ocorrncia de qualquer pacote TCP vindo de uma conexo TCP
previamente estabelecida, ainda que esse pacote fosse spoofado e no fosse um pacote legtimo dessa
conexo TCP. A expresso "spoof" define um tipo de pacote que traz consigo informaes de origem
manipulada, ou seja o pacote no legtimo se faz passar por um pacote que na verdade no ele. uma
tcnica no muito simples e que pode ser evitada de vrias formas, uma delas a verificao pelo
firewall. Nessa nossa nova abordagem, cada regra dinmica criada para uma conexo especfica entre
duas pontas (dois hosts) e suas respectivas portas, ou seja, um pacote TCP spoofado poderia manipular
seu endereo de destino e de origem, mas no manipularia a porta (a no ser com muita sorte) onde a
conexo foi efetivada, e onde a conexo TCP legtima est sendo mantida. Dessa forma a regra 1000
("check-state") falha, no permitindo o roteamento do pacote, e posteriormente a regra seguinte (2000)
tambm falharia, a no ser que o pacote fosse do tipo TCP SYN, e dessa forma o pacote negado pra
regra final da poltica padro fechada do firewall.
Resumindo, os critrios que definem a permisso ou no de um pacote passando por uma regra
dinmica so:
- Protocolo
- Endereo & Porta IP
- Destino & Porta IP
- Tempo da regra esgotado
Como j foi dito, a regra dinmica descarregada depois de certo tempo sem ser utilizada.
Dependendo de como uma regra dinmica utilizada, podemos definir um perodo fixo de tempo at que
a regra se esgote. Esse tempo de durao pra cada tipo de regra dinmica pode ser verificado utilizando as
variveis corretas do sysctl(8). Posteriormente podemos modificar esses valores. Eis a listagem dos
valores padres dessas variveis do sysctl:
eksffa@eeviac~# sysctl -a | grep 'dyn.*lifetime'
net.inet.ip.fw.dyn_ack_lifetime: 300
net.inet.ip.fw.dyn_syn_lifetime: 20
net.inet.ip.fw.dyn_fin_lifetime: 20
net.inet.ip.fw.dyn_rst_lifetime: 5
net.inet.ip.fw.dyn_short_lifetime: 5
eksffa@eeviac~#
A primeira varivel do sysctl(8) indica que o tempo de vida padro pra cada regra dinmica que
use um pacote do tipo TCP ACK 300 segundos. A varivel seguinte indica que o tempo de vida de uma
regra dinmica cujo pacote seja TCP SYN 20 segundos. Na regra seguinte, 20 segundos tambm de vida
23
pra regras com pacotes TCP FIN. Depois 5 segundos de vida pras regras que encontrarem pacotes do tipo
TCP RST ou outros pacotes (UDP, ICMP, etc), conforme indica as duas ltimas variveis do sysctl(8).
Vamos usar um exemplo pra demonstrar como isso funciona na prtica:
1) Uma conexo TCP legtima iniciada da mquina 172.16.0.1 na porta 1234 pra porta 22 do
servidor 192.168.0.1 que fica por trs do firewall. Esse pedido de inicializao de conexo se
consiste de um pacote de sincronizao TCP, ou seja, um TCP SYN.
2) A regra 1000 do firewall faz com que o ipfirewall(4) verifique as regras dinmicas, onde ele
no vai encontrar nenhuma regra referente pacotes TCP vindos de 72.15.0.1:1234 para
192.168.0.1:22.
3) A regra 2000 verificada e combinada, ento o "keep-state" ordena que se crie uma regra
dinmica pras conexes TCP entre as mquinas172.16.0.1:1234 e 192.168.0.1:22, e que essa
regra tenha um tempo de vida de 20 segundos (que o padro pra pacotes TCP SYN).
4) Depois de um segundo, um pacote TCP ACK enviado pro servidor 192.168.0.1:22 em
resposta ao pacote TCP ACK enviado pro cliente, pra confirmar o pedido de uma conexo TCP.
5) Em seguida o pacote vai encontrar a regra 1000 do firewall de novo, que vai verificar pelas
regras dinmicas e encontrar uma regra cujo tempo de vida no tenha terminado, e que esteja
permitindo o roteamento dos pacotes cujo IP e porta de origem sejam conhecidos, assim como IP
e porta do destino. Dessa forma a regra dinmica permite que o pacote trafegue com segurana
pelo firewall.
6) Um pacote TCP ACK spoofado, vindo de um possvel ataque que, em circunstncias
normais danificaria os recursos de rede de uma mquina Windows no preparada, que estivesse
por trs do firewall.
7) A regra 1000 verifica as regras dinmicas e encontra o pacote spoofado com IP e portas de
destino que pertencem a uma regra dinmica existente, contudo o IP e porta pra onde o pacote
deve voltar no corresponde ao da regra (porque foi gerado de forma randmica pelo ataque).
Dessa forma a regra 1000 falha, e a filtragem pelo firewall continua pra regra seguinte.
8) A regra seguinte (2000) verifica que o pacote no do tipo TCP SYN, ento no define
regra dinmica praquele pacote.
9) Consequentemente o pacote bloqueado pela regra padro do firewall que do tipo
fechado.
No nosso primeiro exemplo de regra 'stateful' esse pacote spoofado teria sido aceito, porque a
regra que continha "established" como dependncia teria sido cumprida, pois aceitava todo pacote com
um destino em particular, que tivesse ao menos a 'flag' ACK definida, e o pacote Spoofado cumpriria esse
critrio. J a regra dinmica criada exclusivamente para as duas pontas em comunicao, verificou pela
porta de origem e consequente resposta da conexo, informao que gerada aleatriamente, ou seja, no
existe uma forma lgica de se manipular. Esses so exemplos e rases primrios, contudo poderosos em
relao vantagens das operaes avanadas de 'stateful' do ipfirewall(4). Esse tipo de vantagem o
IPFilter tambm possui.
No exemplo anterior poderamos ter assumido um ataque diferente se o pacote spoofado fosse do
tipo TCP SYN, mas antes de explicarmos isso, vamos dar uma olhada em um tipo de ataque popular
utilizando TCP SYN, ataque esse conhecido como SYN FLOODs.
Pacotes TCP SYN spoofados so usados com muita frequncia em taques de rede. A ao mais
comum desse tipo de ataque consiste em enviar inmeros pacotes TCP SYN (SYN FLOODs) pra uma
determinada estao na rede, de modo que toda a conexo fique em estado de espera, por estarem
esperando suas respostas em fila. Dessa forma o trfego de rede controlado pelo kernel fica saturado,
evitando o roteamento de novas conexes legtimas. Mesmo considerando que o Stack TCP/IP do
FreeBSD desenvolvido de forma eliminar randomicamente conexes TCP que estiverem em fila de
espera de forma inativa, esse tipo de ataque pode ser devastador dependendo da poltica de eliminao das
filas adotado no sistema (via sysctl(8)) e dependendo tambm da largura de banda da rede. Vamos
assumir que, se os pacotes TCP SYN chegarem ao servidor de forma muito rpida, eles vo fazer pedidos
falsos de conexes de forma mais rpida do que eles podem ser eliminados da fila, no sobrando recursos
o suficiente pra tratarmos todas as conexes legtimas que tambm estiverem chegando.
Os primeiros pontos em questo, relacionado esse tipo de ataque, a velocidade do ataque e
velocidade com que esses pacotes podem chegar at o servidor (definido por quo larga seja a banda do
atacante) e depois a velocidade e poder de processamento do servidor que est processando os pacotes
que esto chegando pelo Stack TCP/IP. Felizmente, ns estamos trabalhando com FreeBSD, e o Stack
TCP/IP do FreeBSD mais poderoso do que o de qualquer outro sistema, sejam at mesmo Unix, Linux,
ou alguns outros BSD Unix. De qualquer forma, dependendo do nmero de atacantes ao mesmo tempo, e
da largura da banda dos mesmos, essa velocidade nem sempre o bastante.
24
Como podemos concluir na nossa ilustrao prvia de um ataque TCP ACK Spoofado, qualquer
outro ataque com pacotes de qualquer tipo, SYN ou ACK tambm seriam evitados pelo Firewall, porque
cada novo pacote com porta de IP randomicamente criada no encontraria uma regra dinmica que o
permitisse. Mas de qualquer forma devemos ficar muito atentos em relao ao nmero de regras
dinmicas que poderamos abrir por pacotes TCP SYN spoodados. Mesmo tendo certeza que o Stack
TCP/IP do FreeBSD no seria sobrecarregado por tantas tentativas de conexes, a criao das regras
dinmicas do ipfirewall(4) poderiam ser saturadas, de forma a colocar pacotes em espera. A melhor forma
de evitar isso diminuindo o tempo de vida das regras dinmicas iniciadas por pacotes TCP SYN,
utilizando sysctl(8), como foi mostrado anteriormente, e ainda, aumentar o nmero mximo de regras
dinmicas, atravs de uma outra varivel do sysctl(8):
net.inet.ip.fw.dyn_max: 1000 (default)
Como o seu firewall 'stateful' em plena atividade, voc pode verificar quantas regras dinmicas
existem criadas no exato momento, verificando a varivel do sysctl(8):
net.inet.ip.fw.dyn_count
A melhor forma de evitar que pacotes spoofados utilizem todas as suas regras dinmicas evitar
que qualquer mquina fora da sua rede inicie uma conexo TCP. Isso pode ser feito facilmente com as
seguintes regras, assumindo que a rede 192.168.0.0/27 est por trs do firewall:
add 1000 check-state
add 2000 allow tcp from 192.168.0.0/27 to any out setup \
keep-state
Dessa forma s os pacotes TCP SYN que sarem pelo seu firewall podero ser roteados, ou seja,
os pedidos que entrarem sero automaticamente negados. Esse o mesmo tipo de proteo que o NAT e
proxies transparentes de forma geral oferecem pras mquinas internas.
At agora ns trabalhamos essencialmente com regras 'stateful' que manipulavam conexes TCP.
claro, no pra menos, conexes TCP representam a grande maioria do trfego gerado em rede,
contudo voc se lembra que ns comentamos que o ipfirewall(4) poderia manipular tambm filtragem
'stateful' de outro protocolos. Bom, ento de uma olhada nas regras que ns usamos pra permitir que
nossos clientes internos pudessem pingar qualquer mquina pra fora da rede, enquanto ningum poderia
nos pingar, quando estudamos a seo referente ao "icmptypes". Agora vamos fazer a mesma coisa
usando "check-state" e "set-state":
add 1000 check-state
add 2000 allow icmp from any to any out icmptypes 8 keep-state
J podemos entender facilmente essa regra, que cria uma regra dinmica pra cada pedido de echo
que nossas estaes internas faam pra fora. Quando a resposta chega ela permitida pela regra dinmica
que estabeleceu a conexo entre as duas pontas, e se algum de fora tenta pingar uma mquina interna, a
regra padro nega essa ao. O protocolo ICMP usa a varivel net.inet.ip.fw.dyn_short_lifetime do
sysctl(8). Se a resposta do ping demorar mais que 5 segundos pra chegar a regra vai ser descarregada e o
pacote no vai poder ser roteado. Se voc considera que as respostas de ping levaro mais que 5 segundos
pra acontecer, ento voc, como administrador da rede deve elevar o valor da varivel no sysctl(8). De
qualquer forma a maioria dos atrasos de rede levam menos de 1 segundo, a no ser que seja IRC ;-)
A regra 2000 ainda poderia ter definido uma faixa de rede com permisso pra fazer o ping, caso
existisse mais de uma rede por trs do firewall, e apenas uma delas poderiam pingar mquinas externas.
Na verdade escolhemos a regra assim porque a forma que mais se aproxima do nosso exemplo inicial de
controle do ping.
25
26
7.2. Dummynet;
Todas as outras funcionalidades pra se implementar Traffic Shapping requer o uso do
dummynet(4), que foi incorporado na verso 2.2.8 do FreeBSD. Pra isso precisamos adicionar uma opo
ao nosso Kernel:
options DUMMYNET
Depois de compilado o nosso kernel com mais essa opo (alm das opes tpicas do
ipfirewall(4)), o administrador do sistema vai poder especificar a criao de tneis (chamados "pipes")
pra controle do trfego. Um tnel nada mais do que uma regra de Traffic Shapping que controla o
roteamento, canalizando as informaes que posteriormente iro trafegar por endereos especficos de
rede. A criao desses tneis feita com o comando "pipe" do ipfw(8). O trfego redirecionado esses
tuneis por meio do comando "pipe <pipe #>" no ipfw(8). Vamos ento criar um tnel simples:
pipe 10 config bw 100Kbit/s
27
Note que, assim como nas regras de firewall, o "pipe" apenas mais uma ao pro ipfw(8),
exatamente como "add" ou "delete", portanto antes de cada comando feita uma chamada ao ipfw(8)
(/sbin/ipfw pipe 10... por exemplo).
Esse tnel simples que criamos logo acima vai limitar o fluxo de informaes pra uma
velocidade mxima de 100 Kilobits por segundo. Existem vrias maneiras distintas de indicarmos as
medidas de velocidade de trfego: bit/s, Byte/s, Kbit/s, Kbyte/s, Mbit/s, Mbyte/s. Cada tnel de limitao
de banda deve usar a opo "bw" (de bandwidth banda).
Uma outra maneira de controlar trfego usar a opo "delay" que fora um atraso na
comunicao, simulando o que se conhece como "lag" do sistema:
pipe 10 config delay 100
O valor que segue a opo "delay" o tempo de atraso que ns desejamos, definido em
milisegundos. Nesse exemplo todo o trfego roteado atravs desse tnel ter um atraso de 100ms.
Existe ainda a possibilidade de proporcionarmos uma taxa de perca de pacotes, funo essa igual
"prob" que comentalos logo acima. Por exemplo, pra conseguirmos uma taxa de 20% de pacotes
perdidos (equivalente a "prob 0.8") podemos criar o seguinte tnel:
pipe 10 config plr 0.2
"plr" significa "packet loss rate" (taxa de perca de pacotes), portanto o valor indica que taxa os
pacotes no sero roteados, oposto da opo "prob" do ipfw(8), que indica a taxa dos pacotes que sero
roteados. Pra evitar qualquer confuso com a utilizao de "prob" ou plr", aconselhamos que o
administrador assuma uma escolha pessoal entre as duas possibilidades. Ambas so igualmente efetivas, e
co-existem porque a primeira nativa do ipfirewall(4) enquanto a segunda faz parte do dummynet(4).
7.2.1. Filas de Tneis (Pipe Queues);
Bom, a necessidade seguinte definir o tamanho das filas dos tneis gerados, especialmente se a
MTU da interface de rede em questo relativamente grande. A MTU de uma 'device' de rede define o
tamanho mximo que um pacote vai ter naquela interface. MTU = Maximum Transmission Unit, ou
Unidade Mxima de Transmisso. Pra se obter o valor da MTU em uma interface de rede necessrio o
uso do ifconfig(8):
eksffa@eeviac~# ifconfig xl0
xl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 192.168.0.1 netmask 0xffffffe0 broadcast 192.168.0.31
ether 00:70:18:d4:a4:ac
media: 10baseT/UTP (10baseT/UTP <half-duplex>)
supported media: 10base5/AUI 10baseT/UTP <full-duplex> 10baseT/UTP
<half-duplex> 10baseT/UTP
eksffa@eeviac~#
Verificamos portanto que na interface xl0 em questo, a MTU da placa de rede 1500 (bytes).
Por padro esse valor comum entre as placas de rede.
As filas so utilizadas pelos tneis pra forar as limitaes e atrasos de banda. Elas podem ser
configuradas especificando-se o seu temanho em "Kbytes" ou por "slots". Cada 'slot' corresponde a um
pacote, ou seja definir que uma fila tem 10 'slots' significa que aquela fila vai suportar apenas 10 pacotes
simultneos. O tamanho mximo de cada pacote, por ser definido pela MTU da interface, equivale a
multiplicao do mesmo pelo nmero de pacotes na fila, ou seja se voc criar uma fila (queue) com 10
'slots', o tamanho dela ser 10 x 1500 bytes, portanto 15Kbytes.
importante entender a definio de tamanho das filas (queue) porque o padro pra cada fila
50 'slots', que pode ser muito pra determinadas interfaces de rede com MTU grande e pouca banda
disponvel. O padro 50 'slots' foi definido por ser o tamanho mdio de uma fila nas devices de rede.
Normalmente esse valor o ideal, contudo quando se tem uma banda pequena, a requisio pelas
interfaces maior do que o trfego possvel na rede, isso gera gargalo e consequente atrasos na rede.
Faamos o seguinte ento: vamos criar um tnel em uma rede que simule a velocidade mxima de um
modem de 56K:
pipe 10 config bw 56Kbit/s
28
... mas no vamos definir uma MTU menor pra device, com o ifconfig(8), nem vamos diminuir o
tamanho da fila (queue), que seria nossa melhor opo. A fila pros pacotes ento seria 1500 bytes (12000
bits) x 50, ou seja, 600Kbits de fila. Pra um tnel que esta limitando a banda 56Kbit por segundo,
levaria aproximadamente 10.7 segundos pra uma fila de 600Kbit ser preenchida. Esse um atraso
inaceitvel pra por o trfego em andamento. Pra evitar esse tipo de problema recomendvel ajustar
manualmente o tamanho das filas (queue), em 'slots' que mais fcil pra uma comparao com o padro
(que sabemos ser 50) ou em Kbits" que uma melhor atribuio quantidade de dados. A segunda
opo a melhor, porque alm de ser um valor mais compreensvel, o uso de 'slots' requer que o
administrador tambm defina o valor pra MTU da interface, utilizando o ifconfig(8), j que esse valor
equivale varivel de multiplicao no tamanho da queue (fila). Lembre-se, quanto menor a banda
disponvel, menor deve ser a fila. No nosso exemplo acima, uma configurao rasovel pra fila seria:
pipe 10 config bw 56Kbit/s queue 5Kbytes
7.2.2. Mscaras de Tneis (Pipe Masks);
Uma poderosa caracterstica dos tneis permitir mltiplas filas por fluxo. Por exemplo, imagine
que voc tenha vrias mquinas atrs do seu firewall, e voc quer limitar a banda pra 100Kbits/s pra cada
mquina, ou seja, no vai agregar um valor somatrio banda pra todas as mquinas, vai definir
individualmente a banda. Existem duas formas de se fazer isso, a mais bvia e primeira concluso que um
administrador tomaria seria criar tneis e regras individuais pra cada mquina, com o ipfw(8). Mas agora
considere que voc pode definir mscaras pra identificar um subconjunto de estaes que pertencem ao
mesmo tnel, exatamente como netmasks e bitmasks identificam subconjuntos de estaes que pertencem
a mesma rede.
As mscaras podem ser de seis tipos distintos:
"dst-ip" mscara pro IP de destino do pacote que esta sendo enviado pelo tnel.
"src-ip" mscara da origem
"dst-port" mscara da porta de destino
"src-port" mscara pra porta de origem
"proto" mscara do protocolo
"all" - mscara geral, que especifica todos os bits nos campos (dst-ip, src-ip, etc) como
importantes e vlidos.
Por exemplo, vamos assumir a mesma idia anterior de uma rede atrs de um firewall onde cada
estao deve ter uma banda de 100Kbit/s. Se ns simplesmente direcionarmos todo o trfego pra um
tnel, o valor do trfego ser a somatria de todas as estaes, e no valores individuais. Pra utilizar
mscaras pras estaes s quais o trfego deve ser separado por filas especficas, dessa maneira limitando
a banda de forma separada, faremos o seguinte:
pipe 10 config mask src-ip 0x000000ff bw 100Kbit/s queue 10Kbytes
pipe 20 config mask dst-ip 0x000000ff bw 100Kbit/s queue 10Kbytes
add 1000 add pipe 10 all from 192.168.0.0/16 to any out via <device>
add 2000 add pipe 20 all from 192.168.0.0/16 to any in via <device>
No primeiro instante as definies acima parecem confusas, especialmente porque essa tambm
a primeira vez que ns incluimos as regras do ipfw(8) pra direcionar os pacotes pros tneis. Assumimos
que apenas a definio dos tneis sem o direcionamento com ipfw(8) no faz mais sentido. No tnel
(pipe) 10 ns criamos uma limitao de banda de 100Kbit/s e fila de 10Kbytes pro endereo de origem do
nosso conjunto de estaes. O tnel (pipe) 20 definiu os mesmos valores de bandas e fila (queue) pro
nosso conjunto de endereos de destinos. A regra 1000 definiu que todo o trfego entre a nossa rede sairia
pelo tnel 10, e a regra 2000 definiu que todo o trfego entre a nossa rede interna entraria pelo tnel 20,
sempre (nas duas regras) o trfego ocorreria pela interface <device>.
Existem dois motivos pra termos tneis pra entrada e pra sada do trfego, mas uma delas ns
vamos discutir posteriormente. A primeira questo que deve nos prender ateno no momento que cada
tnel define uma mscara diferente. O tnel 10 define a mscara 0x000000ff pros endereos de origem,
simplesmente porque a regra 1000 direciona todo o trfego que sai (out) pela rede interna, ou seja a
mscara *deve* fazer meno ao endereo de origem, porque cada origem faz diferena quando
queremos filas distintas pra cada estao que origina o fluxo. Da mesma forma o trfego que est
chegando (in) deve ser separado em filas (queue) disntas de acordo com cada endereo de destino.
Voc deve ter percebido que ns especificamos as mscaras em hexadecimal ao invs de decimal
nos tneis. As duas notaes funcionam perfeitamente. As mscaras pros tneis funcionam exatamente da
mesma forma que as 'netmasks', mas a utilizao delas se torna muito mais clara quando ns percebemos
29
que sua aplicao definida de forma reversa, se comparadas. Quando ns utilizamos 'netmask' ns
estamos dividindo a rede em subgrupos, de forma que os bits iniciais so os bits altos, ou seja, os bits
imutveis da subrede. Aqui ns definimos os bits altos como os ltimos bits da mscara, porque cada
tnel roteia os dados de trs pra frente em relao rede. O valor em hexadecimal que ns especificamos
corresponde mascara decimal 0.0.0.255. Bem simples portanto: o ltimo octeto indica que apenas uma
estao ser atribuda por fila (256 menos 255 = 1). Dessa forma atribuida uma fila especfica por
controle de banda pra cada endereo de estao com nmero distinto (no seu ltimo octeto). claro que
estamos supondo aqui que a rede em questo no dever ter mais que 254 estaes, mas caso existam, a
mscara dever ser redefinida. Ento se voc quer definir 254^2 estaes na rede que o firewall vai estar
controlando, a a mscara teria que ser 0.0.255.255 (0000ffff). Isso define que qualquer endereo com um
nico bit diferente entre os dois ltimos octetos (ou seja os 16 ltimos bits baixos) dever ter sua prpria
fila de pacotes.
7.2.3. Remanejamento de Pacotes por Tneis (Packet Reinjection);
Em 99% dos casos, assim que um pacote direcionado um tnel (pipe), a configurao
definida pro tnel que toma parte do pacote, e nesse momento a busca nas regras termina, como de
costume no ipfirewall(4). Contudo voc pode forar que o pacote seja reinjetado (ou remanejado) no
firewall, a partir da regra seguinte, mesmo depois de ter sido direcionado pro tnel. Pra fazer isso basta
desativar a seguinte opo no sysctl(8):
net.inet.ip.fw.one_pass: 1
Essa opo booleana. S pra constar ;-)
30
31
32