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
1
Sumrio
1. Informacoes gerais sobre a Filtragem de Pacotes de Rede 03

2. Acionando o Ipfirewall(4) 04
2.1. O /etc/rc.firewall e firewalls com poltica aberta (OPEN) 05
2.2. Carregando Rulesets (conjunto de regras) 06
2.2.1. Tipos de Firewall pr-definidos 06
2.2.2. Tipos de Firewall Personalizado 07

3. Sintaxe de regras bsicas do Ipfw(8) 08
3.1. Listando Regras Ativas 08
3.2. Comandos bsicos e suas funes 08
3.3. Especificando Protocolos 10
3.4. Especificando endereos de Origem e de Destino 10
3.4.1. Uma introduo Netmask e Bitmask 11
3.4.2. Especificando Portas e Faixas de Portas 12

4. Sintaxe de regras avanadas do ipfw(8) 13
4.1. A ao "unreach" 13
4.2. Controle de Interface e de Fluxo 13
4.3. Combinando tipos de pacotes ICMP e TCP especficos 14
4.3.1. icmptypes 14
4.3.2. tcpflags, setup & established 15
4.3.3. ipoptions 15
4.4. Reconhecendo Pacotes Fragmentados 15
4.5. Filtragem baeada em UID e GID 16

5. Logs (Logging) 17
5.1. Propriedades de Logs 17
5.2. Configuraes de Logs do sistema 17
5.2.1. Opes do Kernel 17
5.2.2. Configurando o syslog(8) 18
5.2.3. Configurao do newsyslog(8) pra fazer rotacionamento de logs (log rotation) 18
5.3. Configurao de log nas regras 19

6. Introduo filtragem 'Stateless' e 'Stateful' de pacotes 21
6.1. Configuraes 'Stateful' Iniciais 21
6.2. Configuraes 'Stateful' Avanadas 22
6.3. Anatomia de uma Regra Dinmica 25

7. Traffic Shapping (controle de trfego) 27
7.1. Probabilidade de Ocorrncias (Probability Matching) 27
7.2. Dummynet 27
7.2.1. Enfileiramento de pipes (Pipe Queues) 28
7.2.2. Mscaras de pipes (Pipe Masks) 29
7.2.3. Remanejamento de pacotes por pipes (Packet Reinjection) 30

8. Fluxo do Trfego pelo Firewall 31

Apndice A: Exemplos de Configuraes de Firewall 32

2
1. Informacoes gerais sobre a Filtragem de Pacotes de Rede.
IPFW(8), a interface de comando do IPFIREWALL(4) o utilitrio mais comum e mais popular
pra implementar a filtragem de pacotes IP e controle de trfego de rede no FreeBSD, e a ferramenta de
FIREWALL nativa com a qual o FreeBSD trabalha por padro (mesmo considerando que, inicialmente o
firewall desabilitado a nvel de kernel). A forma lgica como o IPFW trabalha suas regras parecida
com a adotada em muitos outros filtros de pacotes (Packet Filters), com excesso do IPFilter, que opera
com um padro pra tratar as regras que menos eficiente e requer bem mais cuidado na hora de ajustar o
firewall (se voc tem familiaridade com o ipf(8), por exemplo, perceba a utilizao da chave 'quick',
necessria para que o ipf(8) no traverse a regra inteira, todas as vezes que ela lida; entre outros fatores
particulares de utilizao do IPFilter). Mas isso no tira a qualidade e o poder de implementao de
firewalls do ipf(8), que tem tambm suas prprias vantagens. A escolha final em relao a qual
ferramenta de Filtragem de Pacotes utilizar, uma deciso pessoal, a no ser que voc tenha necessidade
de alguma caracterstica de um Firewall que o outro no possua, contudo, ns vamos abordar uma
comparao entre as duas ferramentas posteriormente.
Como j dito antes, ipfirewall(4) um firewall por filtragem de pacotes, o que significa que ele
atua monitorando pacote-a-pacote todas as conexes, e a partir da srie 4.x do FreeBSD (FreeBSD 4.0), o
ipfirewall(4) tambm pode gerenciar uma filtragem por estado (stateful) de conexes mais rudimentares,
de acordo com estados de conexo. Esse comportamento sempre transparente pros usurios, ou seja,
ningum vai notar que existe um firewall presente, at que um evento aguardado seja bloqueado.
Um firewall costuma ser arquitetado de diversas formas, mas todas as maneiras podem ser
simplificadas com base em duas polticas de filtragem: aberto e fechado. O Firewall que segue uma
poltica aberta permite que todos os pacotes sejam roteados por padro, e bloqueia aqueles que pertencem
a um tipo de conexo que no desejado, ou seja, "abre tudo e bloqueia os indesejados". J o firewall que
segue uma poltica fechada, faz o inverso, bloqueando todo o roteamento de pacotes, e libera um a um o
trfego de conexes permitidas. Essa segunda implementao proporciona um firewall muito mais rgido,
contudo sua configurao bem mais trabalhosa, porque voc pode facilmente bloquear o trfego de
algum servio que esteja sendo utilizado na rede. Alguns protocolos estabelecem conexes dinmicas,
que so bem mais difceis de se prever, mas voc tem como estar atento a esse tipo de situao.
3
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
4

Nesse caso, as opes que ns adicionamos no rc.conf anteriormente no sero *necessrias*,
porque ns no vamos *precisar* do /etc/rc.firewall pra configurar uma poltica aberta de firewall, porque
essa poltica j vai ser iniciada por padro no kernel. Contudo, ainda que voc escolha definir uma
poltica de firewall padro no kernel, interessante adicionar aquelas opes ao /etc/rc.conf porque
posteriormente ns vamos usar o /etc/rc.firewall pra carregar nossas prprias regras de configuraes de
firewall. Adicionar essas opes ao /etc/rc.conf tambm vlido se voc vai carregar o kernel
dinmicamente, porque se eventualmente seu sistema for reinicializado, o mdulo ipfw.ko no vai ser
carregado de forma automtica. As funes de carregamento do firewall pelo /etc/rc.conf permite-nos
carregar o mdulo ipfw.ko automaticamente.
Ainda existem outras opes pro ipfirewall(4) que so possveis se ns formos acionar o firewall
de forma esttica no kernel, at o incio da srie 4.x do FreeBSD algumas dessas opes no podiam ser
acionadas se no fosse de forma esttica no kernel, mas nas verses mais recentes foram definidas
algumas varivies do kernel, mutveis via sysctl(8), que no restringem mais essas opes ao kernel
esttico. Alm do IPFIREWALL_DEFAULT_TO_ACCEPT ns ainda temos as seguintes opes:

options IPFIREWALL_VERBOSE
options IPFIREWALL_FORWARD
options IPFIREWALL_VERBOSE_LIMIT=#

A opo IPFIREWALL_VERBOSE permite logar o trfego de pacotes com o ipfirewall(4),
ecoando informaes sobre atividade dos pacotes pro syslogd(4), em cada regra que tiver a opo "log"
definida. Vamos abord-la com mais detalhes posteriormente.
A opo IPFIREWALL_FORWARD permite que os pacotes sejam redirecionados para outros
hosts, utilizando o comando "fwd" do ipfirewall(4). Redirecionar o pacote (FORWARD) fazer com que
ele siga de um ponto especfico (host, rede, porta) para outro. Vamos tratar desse assunto com mais
detalhes ao longo do documento.
A opo IPFIREWALL_VERBOSE_LIMIT=#define um limite de pacotes que sero logados
para uma regra especfica. Dessa forma, o syslogd(8) no ser sobrecarregado com mensagens relativas
atividades do ipfirewall(4), os comentrios do kernel para essa opo diz que isso uma forma de evitar
negao de servio com os logs gerados para algumas regras de firewall, caso um possvel ataque gere
muitas ocorrncias da mesma regra. O "#" deve ser substitudo com o nmero de vezes que se deseje que
as atividades de cada regra seja logada. Dessa forma, se definirmos, por exemplo
IPFIREWALL_VERBOSE_LIMIT=100 (padro), quando existirem 100 ocorrncias da mesma regra, as
informaes sobre a atividade de pacotes daquela regra deixar de ser logada.
Se voc usa IPv6, as seguintes opes no kernel tero efeito correspondente sobre as aes do
firewall quanto a pacotes IPv6:

options IPV6FIREWALL
options IPV6FIREWALL_VERBOSE
options IPV6FIREWALL_VERBOSE_LIMIT=100
options IPV6FIREWALL_DEFAULT_TO_ACCEPT

Pra habilitar as mesmas opes do ipfirewall(4) sem recompilar o seu kernel, voc vai definir as
variveis correspondentes por meio do sysctl(8), por exemplo:

eksffa@eeviac~#sysctl -w net.inet.ip.fw.verbose=1
eksffa@eeviac~#sysctl -w net.inet.ip.fw.verbose_limit=100
eksffa@eeviac~#sysctl -w net.inet.ip.forwarding=1

Ainda existem mais quatro opes relacioadas ao ipfirewall(4) que podem ser definidas no
kernel, mas no sero discutidas no momento, porque no so necessrias para a implementao bsica de
um firewall. Essas opes envolvem situaes mais complexas e especficas de roteamento de pacotes, e
vamos tratar delas assim que comearmos a tratar essas configuraes.

2.1. O /etc/rc.firewall e firewalls com poltica aberta (OPEN firewalls);
Ainda que voc defina ou no o tipo de firewall que voc vai estar trabalhando, sempre que a
opo firewall_enable="YES" adicionada no rc.conf e o sistema iniciado, o /etc/rc.firewall lido e
executado tambm, a partir das configuraes definidas no rc.conf, e os seguintes comandos so sempre
adicionados ao ipfw(8):
5

${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).

2.2. Carregando Rulesets (conjunto de regras);
Existem duas opes distintas em relao um comjunto de regras pro seu firewall: a primeira
opo usar uma das definies de firewall j existentes no rc.firewall, e a segunda criar sua prpria
definio, com seu prprio conjunto de regras. Os autores do firewwall nativo do FreeBSD, ipfirewall(4),
recomendam o segundo caso, por duas rases simples:
- Voc pode customizar suas regras de firewall pra satisfazerem da melhor forma as
suas necessidades, sem nunca tocar no rc.firewall, que pode ser mantido como uma referncia
geral sempre que voc precisar.
- Voc vai ser obrigado a se familiarizar com o uso do ipfw(8) e sua sintaxe, se tornando
mais experiente na definio de firewall, e ficando mais a vontade com o ipfw(8).

2.2.1. Tipos de Firewall pr-definidos;
bvio que a deciso final a do administrador da rede, ou do responsvel pelo firewall, no
caso voc que est lendo esse documento. Se voc preferir usar os conjuntos de regras de firewall pr-
definidos no rc.firewall, ento recomendado que voc leia todas elas, pra se tornar familiar e saber
exatamente como cada tipo de firewall funciona, antes de ativar qualquer um dos tipos pr-definidos. O
controle que gerencia qual definio de firewall carregar feito pela opo firewall_type="" no rc.conf.
Alm de "OPEN" existem ainda mais 3 tipos de firewall disponveis:
6
"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 no-
roteaveis, conforme definido no Internet-Drafts da IETF (disponvel em http://www.ietf.org/internet-
drafts/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.
7
3. Sintaxe de regras bsicas do Ipfw(8);
A sintaxe das regras de firewall no FreeBSD so simples. Qualquer regra pode ser adicionada
pelo console, com o comando ipfw(8). Antes de nos aprofundarmos nas sintaxes das regras do
ipfirewall(4), contudo, vamos verificar como podemos listar as regras que esto ativas no momento.

3.1. Listando Regras Ativas;
A forma mais simples possvel de se listar as regras ativas no firewall:

root@eeviac~#ipfw list

Dessa forma, voc vai estar listando todas as regras ativas no momento, seguindo a ordem do
nmero da regra. Por exemplo:

root@eeviac~#ipfw list
00101 deny log logamount 100 tcp from any to 192.168.1.0/24 12345
00102 deny log logamount 100 tcp from any to 192.168.1.0/24 21
00103 allow tcp from any any
65535 deny all from any to any

Dessa forma, ainda que, a regra nmero 00103 tenha sido adicionada antes da regra 00101, a de
nmero menor ser mostra antes, porque a ordem das regras tambm influi na forma como o ipfirewall(4)
vai se comportar.
Pra mostrar a data e hora da ltima vez que um pacote coincidiu com uma regra basta usar a
opo timestamp do ipfw(8):

root@eeviac~#ipfw -t list
00101 Fri Sep 21 06:31:23 2001 deny log logamount 100 tcp from any to
192.168.1.0/24 12345
00102 Tue Sep 18 00:33:12 2001 deny log logamount 100 tcp from any to
192.168.1.0/24 21
00103 Sat Sep 22 19:12:15 2001 allow tcp from any any
65535 deny all from any to any

root@eeviac~#date
Sat Sep 22 19:12:24 GMT 2001

Ou seja, nesse caso, a ltima vez que a regra 00101 bloqueou um pacote foi na madrugada do dia
anterior, a regra 00102 bloqueou um pacote tambm aos 33 minutos de 2 dias atrs, e o ltimo pacote
permitido pelo firewall foi h 9 segundos. Detalhe no comando date posterior que ilustra a data corrente.
Por ltimo, se ns queremos listar o nmero de vezes que um pacote passou (ou foi bloqueado)
por uma regra, e o nmero de bytes que esse trfego gerou, podemos fazer o seguinte:

root@eeviac~#ipfw -a list
ou
root@eeviac~#ipfw show

Os dois comandos vo apresentar as mesmas informaes, dispostas da mesma maneira. A
primeira coluna o nmero da regra, em ordem como ela verificada. A segunda coluna informa quantas
vezes aquela regra coincidiu com um pacote, seguido do (terceira coluna) nmero de bytes que
trafegaram pela regra, e finalmente a regra em s. Existem algumas sintaxes curtas pra esses comandos.
Por exemplo, "ipfw s" tem o mesmo efeito que "ipfw show"; "ipfw l" o mesmo que "ipfw list", etc.

3.2. Comandos bsicos e suas funes;
A partir de agora ns vamos, gradualmente, analisarmos cada opo e comandos disponveis pra
se construir um conjunto de regras de firewall. Por enquanto no vamos abordar regras com as opes de
stateful, ou seja, estaremos trabalhando com regras stateless. Durante os nossos exemplos, no vamos
estar utilizando o programa de controle do firewall (o /sbin/ipfw), que deve preceder cada um dos nossos
comandos, caso estejamos configurando as regras de forma manual, pelo console do FreeBSD. O padro
abordado como deve ser quando estamos trabalhando com um arquivo de regras pra ser passado pro
ipfw(8) via firewall_type="/caminho/pro/arquivo.firewall" no rc.conf.
8

add 1000 allow all from any to any

Esse o exemplo mais simples de uma regra. Ns j encontramos a mesma regra anteriormente,
com uma nica diferena, que era o nmero da regra. Lembre-se que, na seo 2.1 quando ns discutimos
sobre tipos de firewall "OPEN" (aberto) ns trabalhamos com o parmetro "pass", que como ele foi
usado no rc.firewall. Bom, acontece que "pass", "allow" e "permit" so sinnimos pro ipfirewall(4), eles
tem o mesmo efeito, contudo as variaes permitem que o administrador fique o mais a vontade possvel
para escrever as suas regras quase que de forma literal. Nessa regra, "all" (todos) os pacotes vindos de
"any" (qualquer) lugar para "any" (qualquer) destino so permitidos ("allow").
No ipfirewall(4), grande parte das vezes, sempre que um pacote combinar com uma regra, o
ipfirewall(4) pra de examinar as outras regras pra aquele pacote, ou seja, a ordem como as regras so
processadas no firewall do FreeBSD so do tipo "first match wins" onde, a primeira constatao do
pacote evita que as outras sejam lidas. Por isso extremamente importante estar atento a ordem (nmero)
das regras. Sob circunstncias especiais as outras regras podem ser procesadas.
Ento, de forma geral, a sintaxe mais simples pro ipfw(4) :

<comando>[<nmero da regra>] <ao><protocolo>from <origem>to <destino>

Os <comandos>mais importantes so "add" e "delete". Uma simples traduo seria o suficiente
pra explicar que "add" adiciona uma regra e "delete" a exclui. O <nmero da regra>varia de 0 at 65535,
e indica a ordem que essas regras sero processadas no firewall, portanto a ltima regra sempre define a
poltica padro do firewall no kernel. Mesmo se voc tiver uma poltica de firewall aberta (OPEN)
definida no seu /etc/rc.conf, a ltima regra vai sempre indicar a poltica do kernel. Isso timo porque,
como a ordem de busca das regras para de processar ao encontrarem uma regra que combina com o
pacote, e se a penltima regra a de nmero 65000, definida pelo rc.firewall pra permitir todo o trfego
da rede, ento todo trfego vai ser liberado, mesmo que a ltima regra (65535) negue todos os pacotes, j
que essa regra nunca vai ser processada.
"<ao>" na sintaxe do ipfw(8) pode ser uma das seguintes:

"allow" | "pass" | "permit" | "accept" - Quando uma regra define essa ao, sempre que
um pacote combinar com essa regra, ser permitido seu roteamento pelo firewall, e o processamento das
regras *pra esse pacote* termina.

"deny" | "drop" - Qualquer pacote que combinar com uma regra cuja ao seja "deny"
ou "drop" so silenciosamente bloqueados pelo firewall, e o processamento das regras pra esse pacote
termina.

add 1100 deny all from any to any

Essa regra nega todos os pacotes vindos de qualquer origem e indo pra qualquer destino.

"reset" - Quando um pacote encontra uma regra com essa ao, o pacote bloqueado, e
o ipfirewall(4) tenta enviar um sinal (flag) de TCP Reset (RST) pro endereo de origem do pacote. O
processamento das regras pra esse pacote termina. Como esse tipo de regra apenas se aplica pra pacotes
TCP, o protocolo especificado na regra deve ser "tcp", para que apenas tais pacotes sejam processados
por essa regra, e no todos (proto "all") os protocolos de pacotes IP.

Vale notar que o uso do "reset" pode ser muito interessante pra enganar ferramentas que
escaneiam as redes (network scanners), j que normalmente podem detectar um servio por trs de uma
porta filtrada, mesmo que ele esteja por trs de um firewall de bloqueio. Por outro lado, se algum estiver
praticando um ataque do tipo "network flood" em uma porta especfica a qual o ipfirewall(4) est
configurado para responder com pacotes RST, isso duplicaria o uso da sua banda de rede. Uma soluo
simples bloquear, com uma regra prvia o endereo da mquina que est agindo dessa forma, endereo
esse obtido de forma dinmica por monitoramento.

add 1200 reset tcp from any to any

Essa regra 'precria' (risos) bloquearia todas as conexes TCP vindas de qualquer destino, indo
para qualquer origem, e responderia com um pacote RST para cada uma delas.
9
"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.

3.3. Especificando Protocolos;
Protocolo (proto) em "protocolo" na sintaxe bsica de uso do ipfw(8), o protocolo de
comunicao que voc quer que aquela regra combine. Definies de protocolos do tipo "ip" ou "all" so
especificaes gerais que englobam todos os protocolos. Os protocolos mais comuns so "icmp", "udp" e
"tcp", mas a relao de protocolos com os quais o ipfirewall(4) trabalha enorme. Na verdade so todos
os protocolos possveis de uma rede. Para uma lista completa das possibilidades, fique a vontade:

root@eeviacbsd~#cat /etc/protocols

3.4. Especificando endereos de Origem e de Destino;
O endereo de destino e de origem de um pacote tem o mesmo formato em uma regra de
firewall. Eles podem ser um nome, definido no /etc/hosts e resolvido por DNS, pode ser um endereo IP,
um endereo de rede com mscara de rede (bitmask/netmask) e, ainda podem definir uma ou vrias
portas, se o protocolo for tcp ou udp. Usar nomes ou endereos IP indiferente, basta atentar ao fato que
a resoluo de nomes via DNS pode mudar sem seu conhecimento prvio.

add 1000 allow all from minhamaquina to outramaquina
add 1100 deny all from 10.0.0.5 to any

A primeira regra permite todo o trfego vindo da "minhamaquina" para a "outramaquina", e a
segunda regra nega toda conexo da mquina 10.0.0.5 para qualquer outra estao. Sempre que um pacote
coincidir com uma regra do firewall, o processamento pra aquele pacote termina, e o pacote permitido
ou negado, de acordo com a ao definida pela regra. Esse um exemplo muito simples de um filtro
baseado em estaes, ou "host-based filtering", que filtra de acordo com o destino ou origem do pacote.
Um firewall por filtragem de redes funciona de forma similar, distinguindo-se apenas a notao de redes,
onde necessrio definir a mscara de subrede (netmask) ou ainda o bitmask. Vejamos:

add 2000 allow all from 192.168.0.0/16 to any
add 2100 deny all from any to 10.0.0.0:255.0.0.0

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 Netmask Total de IPs IPs usveis
32 255.255.255.255 1 1
31 255.255.255.254 2 1
30 255.255.255.252 4 2
29 255.255.255.248 8 6
28 255.255.255.240 16 14
27 255.255.255.224 32 30
26 255.255.255.192 64 62
25 255.255.255.128 128 126
24 255.255.255.0 256 254
...
22 255.255.192.0 16320 16318
20 255.255.128.0 32765 32766
16 255.255.0.0 65536 65534
12 255.128.0.0 8.388608+e6 8.388606+e6
8 255.0.0.0 256^3 (256^3)-2
0 0.0.0.0(todos IPs) 256^4 (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. Sintaxe de regras avanadas do ipfw(8);
Embora o overview anterior sobre as criaes de regras do ipfw(8) seja o bastante pra cobrir a
maioria dos cenrios e necessidades simples de um firewall, ele se mostra solenimente curto pra muitas
situaes mais complexas, como por exemplo, quando o sistema possui mais de uma interface de rede
possvel que se queira definir aes especiais para algumas combinaes de pacotes, ou ento que se
queira um maior controle sobre o direcionamento do trfego. Ento, vamos expandir o modelo de sintaxe
que estvamos trabalhando no ipfw(8) para o seguinte:

<comando>[<nmero da regra>] <ao>[log [logamount <nmero>]] <proto>
from <origem>to <destino>[<interface-spec>] [<opes>]

Todas as opes entre colchetes fazem meno novas funcionalidades que iremos discutir
nessa seo. Ns vamos inclusive cobrir uma nova "ao" que no foi relatada anteriormente. A Sintaxe
pode parecer inicialmente confusa, mas ns vamos com calma, e montaremos as regras aos poucos.

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

4.2. Controle de Interface e Fluxo;
Uma das mais importantes funcionalidades do ipfw(8), que no foi comentada anteriormente na
seo 3 desse documento o controle de fluxo e de interface, ou seja, a possibilidade de criar regras que
verifiquem os pacotes de acordo com uma interface em especial (aplicvel quando voc tem um sistema
com mltiplas interfaces de rede). Essas regras podem identificar de onde esses pacotes esto vindo, e em
que direo esto indo. At agora o senso de direo que ns adotamos simplesmente definia os
endereos de origem e de destino, mas usar apenas essas opes pra definir de onde um pacote est vindo
ou pra onde ele est indo via firewall no muito confivel. Quando voc quer filtrar pacotes que esto
apenas entrando ou saindo pela rede, as opes "in" e "out" podem ser utilizadas com preciso. Ambas
opes ("in" e "out") correspondem ao campo "interface-spec" no modelo de sintaxe dado anteriormente,
e normalmente, so definidas prximas ao final de cada regra, antecedendo qualquer possvel opo extra.
Dessa forma, quando decidirmos filtrar todos os pacotes vindos de qualquer lugar e indo pra qualquer
lugar, poderamos definir:

add 1000 allow all from any to any in

Pra filtrar pacotes indo atravs de uma interface em particular, podemos usar a opo literal
"via", seguida do nome da interface. Dessa forma, se estivermos usando uma placa de rede 3Com 3c59x
PCI, sua interface ser "xl0". Pra filtrarmos qualquer pacote, vindos especialmente dessa interface, com
origem e destinos quaisquer, o seguinte seria o suficiente:

add 1100 allow all from any to any in via xl0

Ou talvez, se voc tiver um sistemas com mltiplas interfaces, e quiser filtrar todos os pacotes
vindos de qualquer lugar e indo pra qualquer lugar, mas que esteja ao menos saindo via *alguma*
interface, pode fazer o seguinte:
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.

4.3. Combinando tipos de pacotes ICMP e TCP especficos;
Pacotes ICMP, TCP e IP so apresentados em vrios formatos distintos. Esses tipos de pacotes
so definidos por vrias _flags_ (opes de identificao). Ns podemos filtrar cada um desses tipos
usando uma das seguintes opes do ipfw(8), ao final de cada regra:

4.3.1. icmptypes (tipos icmp);
"icmptypes <tipo>" - Essa opo filtra o pacote ICMP do <tipo>definido, e inverte a opo se
uma '!' (exclamao) for devinida antes do <tipo>, ou seja, todos os pacotes que no forem desse tipo
sero combinados. Existe, atualmente 15 tipos diferentes de pacotes ICMP que podem ser filtrados; cada
um definido por um nmero. Voc pode ainda especificar faixas de 'icmptypes' utilizando hfen ou
separando-os por vrgula. Os 15 tipos de pacotes ICMP so:

0 - Echo Reply (Resposta de Echo)
3 - Destination Unreachable (Destino Indisponvel)
4 - Source Quench (Origem extinta)
5 - Redirect (Redireo)
8 - Echo Request (Pedido de Echo)
9 - Router Advertisement (SPAM de roteamento? :-))
10 - Router Solicitation (Pedido de Roteamento)
11 - Time-to-Live Exceeded (TTL Excedido)
12 - IP header bad (Cabealho IP malformado)
13 - Timestamp Request (Pedido de Timestamp)
14 - Timestamp Reply (Resposta de Timestamp)
15 - Information Request (Pedido de Informao)
16 - Information Reply (Resposta de Informao)
17 - Address Mask Request (Pedido de Mscara de Rede)
18 - Address Mask Reply (Resposta de Mscara de Rede)

Se voc ficou curioso pra saber como esses tipos ICMP, especialmente o tipo 3, correspondem
aos cdigos de indisponibilidade que podem ser criados com a opo "unreach", ento, saiba
simplesmente que o tipo 3 identifica qualquer um desses cdigos, ou seja, todos. Usar filtros de pacotes
ICMP muito til, especialmente pra controlar ping; por exemplo, voc pode permitir que qualquer
cliente dentro da sua rede interna pingue qualquer estao pra fora da rede, enquanto voc bloqueia que
qualquer estao externa pingue o seu gateway, ou qualquer outro cliente interno. As trs regras a seguir
definem isso facilmente:

add 1000 allow icmp from any to any out icmptypes 8
add 1100 allow icmp from any to any in icmptypes 0
add 1200 deny icmp from any to any in icmptypes 8

A primeira regra permite que todos os pacotes icmp do tipo 8 (pedido de echo) possam trafegar
pra fora do firewall. A segunda permite que todos os pacotes icmp do tipo 0 (resposta de echo) entrem
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.

4.4. Reconhecendo Pacotes Fragmentados;
Pacotes fragmentados podem ser filtrados com a opo "frag" do ipfw(8). Na grande maioria dos
casos, os pacotes fragmentados devem ser bloqueados pelo firewall. Receber um nmero grande de
pacotes fragmentados pode indicar a eminncia de um ataque do tipo DoS (Denial of Service - ou
Negao de Servio). Mesmo considerando que o FreeBSD, e a maioria dos outros sistemas UNIX de
verdade no so sucetveis a esse tipo de ataque, os sistemas Windows so frequentemente muito
vulnerveis. Dessa forma, se voc tem clientes Windows por trs do firewall, dentro da sua rede,
recomendvel bloquear pacotes fragmentados pra protege-los.
Quando voc for usar a opo "frag" pra filtrar (e bloquear) os pacotes fragmentados, tem duas
regrinhas bsicas que voc deve seguir. A primeira que voc no pode usar "frag" quando tambm
estiver usando a opo "tcpflags"; voc define qualquer pacote fragmentado, ou no define nenhum. A
segunda: voc tambm no pode utilizar o "frag" se estiver especificando portas TCP ou UDP; voc
bloqueia todos os pacotes fragmentados, no importando pra qual porta ou servio eles estejam sendo
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

4.5. Filtragem baeada em UID e GID;
Uma poderosa funo que outros firewall (como o IPFilter) no possuem a filtragem de pacotes
baseada em GID/UID. O Ipfirewall(4) tem a capacidade de filtrar pacotes de acordo com o UID ou GID
do dono do processo o qual originou uma conexo. Por motivos lgicos s se pode filtrar pacotes que
tenham sido gerados por processos locais. As opes a serem utilizadas so "gid" ou "uid" seguidos do
GID/UID ou do nome do usurio/grupo que estivermos filtrando.
Um uso em potencial dessa funo restringir o nmero de IPs virtuais em um servidor de shell.
Se voc quer se assegurar que um ou mais Hosts Virtuais no podero ser usados por ningum mais que o
dono do IP virtual, voc pode definir uma regra baseada em filtragem de UID, para que, dessa forma,
todo o trfego do host virtual que no seja do prprio usurio seja bloqueado:

add allow tcp from any to 172.16.0.10 in
add allow tcp from 172.16.0.10 to any out uid patrick
add deny tcp from 172.168.0.10 to any

Essas regras permitem que apenas o usurio 'patrick' vai poder utilizar a alias de IP (Apelido de
IP, IP-Alias ou IP vhost) 172.168.0.10 pra estabelecer conexes TCP pra fora da rede. Ningum mais ser
permitido pendurar Bots, Clientes de IRC ou qualquer outra coisa que precise estabelecer conexo TCP
(quase tudo) nesse endereo IP. O protocolo UDP tambm pode ser usado para filtragem de pacotes
baseada em UID/GID, contudo nenhum outro protocolo fora esses dois podem.
Outra utilizao possvel pra UID/GID seria habilitar limitao de uso de banda para cada
usurio, ao invs de limitar pra cada estao ou rede. Por exemplo, voc pode definir um grupo de
usurios que tenham contas rpidas de FTP, definindo uma regra pro GID em questo, e em contrapartida
ter um grupo de usurios de shell que no precisam de muita banda. Vamos ilustrar outras limitaes de
bandas definidas por GID posteriormente, quando estivermos cobrindo o "traffic shaping" com
ipfirewall(4).
Por motivos de segurana, talvez seja necessrio voce logar o trfego de rede de um usurio em
particular, e nesse caso o filtro baseado em UID/GID tambm viria bem a acalhar. Na verdade sempre que
se queira definir um comportamente distinto do firewall com base no usurio que acessa o servio, o
UID/GID do ipfw(8) sempre vem bem a acalhar. Uma pequena dica sempre definir as regras baseadas
em UID/GID antes das outras regras, visto que o ipfirewall(4) termina a verificao da lista das regras
quando um pacote combina com alguma das regras em uso. Isso garante desempenho e evita que se
bloqueie ou permita um pacote antes de verificar qual usurio originou o trfego.
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;

5.2. Configuraes de Logs do sistema;
5.2.1. Opes do Kernel;
Pra habilitar os logs do ipfirewalll(4) no FreeBSD, voc tem que incluir ao menos as seguintes
opes no kernel (no se esquea de iniciar seu sistema com o novo kernel aps a compilao do mesmo):

options IPFIREWALL_VERBOSE

Voc ainda pode habilitar a seguinte opo:

options IPFIREWALL_VERBOSE_LIMIT=#

Ns j mencionamos essas opes anteriormente, quando estavamos revendo a ativao do
firewall. Essa segunda opo do kernel limita o nmero de mensagens consecutivas enviados ao sistema
de logs do FreeBSD, o syslogd(8), quando dada regra do firewall ativada. Portanto, quando voc aciona
essa opo no kernel, o nmero de mensagens consecutivas relacionada a uma conexo em particular
limitada ao valor (nmero) especfico. Considere o seguinte:

options IPFIREWALL_VERBOSE_LIMIT=10

Com essa entrada definida no seu kernel, apenas 10 mensagens consecutivas a respeito de
determinada conexo sero logadas no syslogd(8), e todas as outras ocorrncias seriam identificadas sob
uma expresso genrica como por exemplo:

J an 29 03:26:55 meuservidor last message repeated 45 times

Normalmente essas mensagens so logadas em /var/log/messages alm de serem impressas no
console do sistema tambm. Se voc quiser modificar esse comportando do syslogd(8), voc ter que
editar o /etc/syslog.conf. O syslog.conf(5) oferece uma flexibilidade considervel em relao
configurao sobre as formas com que o syslogd(8) vai tratar as mensagens do sistema. O limite definido
pra IPFIREWALL_VERBOSE_LIMIT fica critrio do administrador, mas valores acima de 10 j
proporciona um trfego alto de mensagens em servidores muito requisitados. Mas se voc quer definir um
arquivo separado pra logar tudo de forma distinta, ao invs de simplesmente logar no arquivo padro
(/var/log/messages), isso pode ser feito tambm, e ainda, se voc julgar ter espao em disco o bastante pra
trabalhar com rotacionamento de logs (Log Rotation) voc no precisa definir a opo de limite de
verbosidade no Kernel.



17
5.2.2. Configurando o syslog(8).
Voc pode configurar o syslogd(8) pra logar as atividades do ipfirewall(4) em um arquivo
separado, seguindo trs passos relativamente simples:
1) Crie o seu novo arquivo de log para o ipfw(8) e, como alternativa, crie tambm o diretrio de
logs que voc achar conveniente. Vamos assumir ento que voc quer que todos os logs relativos
ao ipfirewall(4) sejam armazenados em /var/log/ipfw/ipfw.log. Dessa forma voc vai ter que
criar o diretrio em questo (/var/log/ipfw) e em seguida o arquivo de log (ipfw.log) sob tal
diretrio, pra isso vai utilizar o comando touch(1):
eksffa@eeviac~#mkdir /var/log/ipfw && touch /var/log/ipfw/ipfw.log
eksffa@eeviac~#
Tenha certeza que o diretrio e arquivo em questo no tenham permisses de leitura pra outros
usurios seno o dono do arquivo, por questes bvias de segurana.

2) Configure o syslog.conf(5) pra enviar todas as mensagens relativas ao ipfirewall(4) pro
arquivo /var/log/ipfw/ipfw.log. A forma mais fcil de fazer isso adicionar as seguintes linhas
no final do syslog.conf(5):
!ipfw
*.* /var/log/ipfw/ipfw.log
Atente pra usar <TAB>(tecla tab) nesse arquivo ao invs de espaos simplesmente. Mesmo
assumindo que usar "tabs" no obrigatrio no FreeBSD pro arquivo /etc/syslog.conf, de bom
costume faz-lo, caso voc trabalhe tambm com outros UNIX, cuja maioria no aceita espaos
no syslog.conf(5). Portanto mesmo voc podendo ignorar a mensagem de advertncia no incio
do /etc/syslog.conf, sempre bom manter o bom hbito seguro de usar o syslog.conf(5) da forma
indicada por ele.
Voc vai reparar que as mensagnes do tipo "last messages repeated #times" (ou seja: ltimas
mensagens repetidas #vezes) sero tambm logadas, alm desse arquivo, pra qualquer outro cujo
syslog.conf(5) aponte as seguintes entras:
*.err, kern.debug, *.notice
E ainda, o console tambm ir receber todas essas mensagens, como definido na linha:
*.err;kern.debug;auth.notice;mail.crit /dev/console
Lembre-se que o console na verdade apenas o ttyv0 (ALT+F1). Os consoles virtuais e pseudo
terminais se comportaro de forma distinta em relao mensagens. Por padro as seguintes
linhas definiro quando as mensagens forem enviadas pra outros terminais:
*.err root
*.notice;news.err root
*.alert root
*.emerg *
As linhas *.err e *.notice iro logar mensagens do kernel e tambm as exibiro no terminal onde
o usurio especificado estiver logado. Note que o usurio em questo o 'root', ento, como por
padro voc no deve logar como root a toa, o usurio root ser sempre alertado. No se
recomenda de forma alguma que essas linhas sejam comentadas, informaes de log para o root
e pro terminal so extremamente importantes pra se manter atento a qualquer coisa errada que
estiver acontecendo com o servidor. Se por bom senso voc costuma estar muito logado com
outro usurio que no seja o root, tambm considervel configurar o syslogd(8) pra alertar o
seu usurio.
Ento vamos resumir o que deve ser feito quando voc for configurar seus logs pelo arquivo de
configurao syslog.conf(5):
Insira a linha com "!ipfw" e indique o caminho pra onde as informaes referentes s atividades
do Firewall devem ser logadas.
No altere as mensagens que sero enviadas ao usurio Root se ele estiver logado. Indique os
mesmos alertas pra um usurio que voc usa com mais frequncia.
3) Envie um sinal de reinicializao pro processo do syslogd(8). A forma mais fcil usando o
comando:
eksffa@eeviac~#killall -HUP syslogd
eksffa@eeviac~#

5.2.3. Configurao do newsyslog(8) pra fazer Rotao (ou Rotacionamento) de Logs (log rotation);
Agora que o ipfirewall(4) est configurado pra logar todas suas atividades, voc deveria pensar
seriamente em configurar o newsyslog.conf(5) de forma a garantir que o newsyslog(8) v rotacionar os
logs do ipfirewall(4), ou, como alternativa, optar por algum outro mecanismo de rotacionamento de logs.
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.

5.3. Configurao de Log nas Regras;
Uma vez que tudo esteja pronto pra utilizar as funes de logs do ipfirewall(4), vamos comear a
definir quais regras ns queremos logar quando elas forem filtradas. Existem dois parmetros bsicos pra
usarmos em conjunto com nossas regras pra definirmos que queremos logar *aquela* regra. Vejamos:
"log" o parmetro mais comum. Toda vez que uma regra que for definida o "log" for
acionada, ento a ao definida ("action") por aquela regra ser logada todas as vezes que um pacote
coincidir a regra. Por isso tome muito cuidado pra no defnir "log" pra uma regra que a tero pacotes
frequentementes assimilados a ela, como por exemplo:

add 0500 allow log all from any to any

Essa uma regra que permite todo o trfego de todos os tipos de pacotes de todas as redes pra
todas as redes, ento imagine a frequncia de informaes que sero logadas sempre que cada pacote for
permitido pelo seu firewall. Esse tipo de regra pode facilmente proporcionar problemas pro seu disco
local ;-)
Por outro lado, definir "log" pra uma regra geral de negao uma pedida considervel:

add 65000 deny log all from any to any

Essa regra mais considervel, porque uma das ltimas, em uma poltica clara de firewall do
tipo "CLOSED" ou seja, tudo que deve ser permitido j o foi nas regras anteriores que suponhamos
existir, portanto nos interessa manter logs das conexes negadas. Alm do que o nmero da regra 6500,
o que, em relao regra anterior (500) muito mais seletiva, visto que uma das ltimas regras a serem
checadas. Preste muita ateno pra escolher quais regras voc quer logar e quais voc no quer.
"logamount <nmero>" - Esse parmetro em seguida ao "log" define o nmero mximo de vezes
que uma regra vai ser logada. Esse parmetro anlogo entrada de limite de verbosidade no kernel, e da
muito mais controle ao administrador que pode, por exemplo, definir um nmero baixo pra uma
determinada regra, e zerar a mesma uma vez ao dia, dessa forma s deixando de logar o perodo que um
possvel ataque ocorrer. Essa definio possvel no FreeBSD 4.x, FreeBSD 2.2.x e FreeBSD srie 3
acina de 3.4.x. Nas verses anteriores 3.4 no FreeBSD 3.x o padro do "logamount" era 10.
Sempre que uma regra logada, as informaes geradas pra tal pacote so:
- Data & Hora
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
6. Introduo filtragem 'Stateless' e 'Stateful' de pacotes;
A filtragem de pacotes do tipo 'Statefull' e 'Stateless' so dois termos frequentemente encontrados
em discusses cujo assunto seja ipfilter(4) e ipfirewall(4). O modo de filtragem 'Stateless' tende a tratar
cada pacote roteado pelo firewall como pacotes individuais, que no tenham associao alguma com
qualquer outro trfego que tambm estiver passando pela dada interface do firewall. Esse tipo de
filtragem o mais comum e o mais fcil de implementar, e tem vantagens efetivas quando se pretende:
- filtrar pacotes corrompidos (fragmentados)
- filtrar pacotes de protocolos especficos (icmp, udp, igmp, etc)
- fazer um firewall baseado em host (ou seja filtrando de acordo com o destino e/ou
origem do pacote)
J uma filtragem do tipo 'Stateful' mais complexa de ser implementada; esse tipo de filtro trata
o trfego como sendo composto de determinadas conexes, ou seja os pacotes pertencem a uma dada
conexo, negada ou permitida, e no trata pacotes como individuais. Toda a comunicao atravs de
qualquer protocolo usa nmeros de sequncia que indicam em que ordem os pacotes sero lidos em um
socket(2). Esse o primeiro princpio bsico das informaes que um firewall 'Stateful' precisa conhecer.
O segundo que, conexes orientadas protocolos como TCP, geram trfego de pacotes especiais que
indicam o incio de uma conexo (SYN) e o fim da mesma (FIN). Esse ponto tambm essencial a um
firewall do tipo 'Stateful'. No geral, voc deve:
- saber que estado pertence uma conexo (iniciada, no iniciada, em negociao,
terminada, etc)
- ser capaz de determinar se uma conexo esta se comportando de forma esperada, com
procedimentos validos, ou se ela est se comportando de forma indevida. Voc deve ser capaz de filtrar os
pacotes que se comportarem de forma indevida.
Um firewall do tipo 'Stateful' cria regras dinmicas pras conexes que estiverem em andamento,
e elimina essas regras quando a conexo foi terminada. Isso permite ficarmos atento de forma mais
inteligente s atividades da rede. Por outro lado um firewall do tipo 'stateful' so incapazes de filtrar cada
pacote individualmente, exatamente pelo fato dele criar regras dinmicas especiais que permitem uma
conexo em sua totalidade, examinando se o comportamento dessa conexo est aceitvel. Em
compensao, muito fcil juntar regras de firewall do tipo 'stateful' e do tipo 'stateless' em um mesmo
firewall, dependendo apenas do quanto o administrador do sistema bom. E normalmente
administradores de FreeBSD j so muito bons por natureza, portanto podem se beneficiar dos dois tipos
de firewall.
Quase todas as regras que ns apresentamos anteriormente eram 'stateless'. As unicas excesses
foram as regras a respeito das opes "tcpflags," "setup," e "established" que permitiam que ns
checassemos o estado de uma conexo TCP. Vamos ento usar uma combinao dessas regras pra um
primeiro exemplo prtico de regras 'stateful'. Antes um pouquinho de histria. Esse tipo de verificao
primitiva de estado de conexo (tcpflags, etc) existe no ipfirewall(4) faz muito tempo, contudo essas
opes eram as nicas, o que fazia a capacidade do ipfirewall(4) de criar regras 'stateful' muito limitada.
Por isso anteriormente verso 4.x do FreeBSD o ipfirewall(4) era chamado de tipicamente 'stateless',
enquanto o ipfilter era a opo 'stateful' disponvel. A partir do FreeBSD 4.0 o ipfirewall(4) foi habilitado
a trabalhar com funcionalidades 'stateful' mais extensivas, e mais desenvolvimento a respeito disso est
em andamento no ipfirewall(4).

6.1. Configuraes 'Stateful' Iniciais;
Pro nosso primeiro exemplo, vamos estar usando as caractersticas mais bsicas e conhecidas do
ipfirewall(4) pra tratar filtragem 'stateful'. A maioria dos administradores mais atentos que costumam ler
as regras de firewall pr definidas no /etc/rc.firewall, costumaram fazer largo uso das funes "setup" e
"established", que compe a maiora das regras nesse arquivo. Mesmo essas regras podendo ser usadas
exclusivamente pra controlar conexes TCP de forma 'stateful', o que demonstra certa limitao, vamos
criar no nosso primeiro exemplo um conjunto simples de regras que filtram conexes ao servio SSH de
forma 'stateful':

add 1000 allow tcp from any to any established
add 2000 allow tcp from any to any 22 in setup

Vamos assumir que estamos usando uma poltica de firewall fechado (ou seja, firewall_type no
/etc/rc.conf no est definido como "OPEN" e no existe a entrada
IPFIREWALL_DEFAULT_TO_ACCEPT no kernel do sistema). Nesse caso, as duas regras anteriores
vo permitir o roteamento dos pacotes desejados. A regra nmero 1000 vai permitir todos os pacotes que
sejam parte de uma conexo TCP j estabelecida, e ento a verificao das regras subsequentes vai cessar
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. Lembre-
se 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 no-
passivas (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.

6.2. Configuraes 'Stateful' Avanadas;
Como j foi dito, configuraes de firewall 'stateful' usando apenas "setup" e "established" so
muito limitadas. Exatamente por permitir controle de conexes stateful apenas sobre o protocolo TCP,
essa filtragem a mais simples existente. Desde a verso 4.0 do FreeBSD, o ipfirewall(4) adotou
caractersticas 'stateful' baseada em timos argumentos; agora pode-se controlar conexes TCP, UDP e
ICMP de forma 'stateful', alm de outros tipos de pacotes, usando o que ns chamamos de regras
dinmicas.
Regras dinmicas uma caracterstica recente do ipfirewall(4) no FreeBSD 4.x; como seu
prprio nome sugeste, so regras dinmicamente criadas pra conexes independentes. Cada regra
dinmica depois de um certo perodo de tempo sem serem utilizadas so descarregadas. O tempo que uma
conexo TCP leva pra ser terminada pode ser controlada por inmeras varivels do sysctl(8), ou seja, de
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.

6.3. Anatomia de uma Regra Dinmica;
Vamos dar uma olhada na sada que voc devei encontrar quando listar as regras dinmicas de
um firewall 'stateful' no seu FreeBSD:

00100 allow ip from any to any via lo0
00200 deny ip from any to 127.0.0.0/8
01000 check-state
25
02000 allow tcp from any to any keep-state
65535 deny ip from any to any
##Dynamic rules:
02000 9 1255 (T 54, #0) ty 0 tcp, 192.168.0.1 2007 <->204.71.200.245 80

Ns j conhecemos as regras estticas apresentadas, contudo, essa a primeira vez que ns
estamos encontrando uma regra dinmica listada pelo nosso firewall. Vamos examina-la com mais
ateno:
A primeira citao de uma regra dinmica o nmero da regra esttica que a gerou, no nosso
caso, a regra nmero 2000, que tem a opo "keep-state" ajustada, conforme aprendemos anteriormente.
A segunda parte o nmero de vezes que aquela regra foi utilizada, ou seja o nmero de vezes que um
pacote saiu pelo firewall atravs daquela regra, ou o nmero de incidncias da regra, seguido do nmero
total de bytes que os pacotes que passaram por aquela regra rotearam. Entre parnteses encontramos o
valor "T" que indica o "timeout" (o tempo de vida) daquela regra, em segundos. Nesse caso ainda existem
54 segundos de vida para essa regra. A cerquilha (#) indica o nmero da regra, nesse caso essa a nossa
regra nmero 0. O 'ty 0' indica o tipo de regra dinmica em questo. Os tipos de regras correspondem ao
fluxo do roteamento de pacotes atravs daquela regra, ou seja, se ela permite apenas trfego da origem
pro destino, do destino pra origem, ou se a regra bidirecional. No nosso caso temos apenas um tipo
indicado, que o padro: bidirecional. Podemos verificar essa afirmao visualmente, indicado pelo
smbolo "<->" entre a Porta/IP de origem e de destino. Depois do tipo da regra dinmica podemos
constatar o protocolo que a regra ta usando, seguidos do IP/porta de origem, o smbolo de fluxo dos
pacotes (no caso "<->") e finalmente o IP/porta do destino da conexo.
Mesmos depois que uma regra dinmica foi descarregada, voc ainda pode lista-la com o
comando "ipfw list", contudo a regra inativa vai ter um valor de tempo de vida ("T") igual a zero (T 0, #).
Uma vez descarregada, a regra no vai mais aceitar pacotes, simplesmente porque ela no existe mais, at
que a mesma regra seja reiniciada, ou ressucitada pela mesma entrada "keep-state" da regra que a
originou inicialmente. Uma vez descarregadas, as regras tambm podem ser substitudas por novas regras
dinmicamente ativadas. A no ser que todas as regras dinmicas continuem em pleno uso, elas sero
continuamente substitudas por novas regras, especialmente se o nmero de regras dinmicas alcanou o
mximo permitido pelas variveis do sysctl(8).
Veja o seguinte exemplo de listagem das regras do ipfw(8):

00100 0 0 allow ip from any to any via lo0
00200 0 0 deny ip from any to 127.0.0.0/8
01000 0 0 check-state
02000 462 71516 allow tcp from any to any keep-state
65000 186 16464 deny ip from any to any
65535 56146 6054724 allow ip from any to any
##Dynamic rules:
02000 125 22084 (T 300, #48) ty 0 tcp, 200.210.70.151 1180 <->200.210.42.45 22
02000 31 1828 (T 217, #55) ty 0 tcp, 200.210.70.151 1176 <->200.210.42.45 21
02000 15 1372 (T 0, #58) ty 0 tcp, 200.210.70.151 1174 <->200.210.42.45 22

No vamos comentar a listagem acima, cabe a voc entender o que est acontecendo com o
firewall. Note que existe conexes cujo tempo de vida j se esgotou, e ainda assim a mesma foi listada.
Bom, quando voc comear usar regras 'stateful' em grande escala, voc vai perceber o quanto a
sada de um comando pra listar as regras do ipfw(8) vo se tornar perturbadoras, devido ao enorme
nmero de regras dinmicas criadas. O ipfw(8) lista todas as regras dinmicas, mesmo que j
descarregadas pra oferecer controle total do firewall ao administrador, contudo nem sempre voc quer
analisar as regras dinmicas, e apenas as estticas, j que so essas que criam as dinmicas. Nesse caso
uma soluo bvia do mundo Unix seria:

eksffa@eeviac~#ipfw list | grep -v '[<->#]'

Ou se voc quer analisar com cuidado todas as regras, sejam estticas dou dinmicas, uma
soluo utilizar um paginador:

eksffa@eeviac~#ipfw list | less
OU
eksffa@eeviac~#ipfw list | more
26
7. Traffic Shape (controle de trfego);
Controle de Trfego (Traffic Shaping) se refere possibilidade de controlar todo o roteamento
de pacotes pelo seu firewall de diversas maneiras, entre as quais as mais importantes so: limitao de
banda, atrasos no roteamento (delays), criao de filas de fluxo, entre outros. Ele permite que voc
controle a intensidade, direo e disponibilidade do trfego. At agora a gente entendia como controlar
roteamento, a escolha e definio de polticas de permisses ou restries de acesso; agora controlar
trfego passa a significar mais do que simplesmente filtrar quem e quando pode acessar determinado
servio, rede e/ou estaes. A incluso do dummynet(4) no FreeBSD possibilitou um controle de trfego
extensivo, funcionalida essa que o IPFilter tambm no pode oferecer.
Todo gerenciamento mais rudimentar de uma rede, em relao sua infra estrutura bsica de
trfego e roteamento pode ser implementado utilizando-se ipfirewall(4) e dummynet(4). Existem apenas
duas restries: probabilidade de ocorrncias e a utilizao de regras dinmicas. Nenhuma regra de
'Traffic Shapping' pode ser criada de forma dinnica, simplesmente porque invivel, em relao
performance, a verificao da capacidade de banda, atrasos e filas de fluxo em cada regra ser criada de
forma no esttica.

7.1. Probabilidade de Ocorrncias (Probability Matching).
O ipfirewall(4) possui uma ferramenta incrivelmente funcional pra auditar e testar uma rede.
Essa ferramenta permite que o administrador simule a restrio de pacotes de forma aleatria sob vrias
taxas de probabilidade. Essa ferramenta estatstica faz uso da opo "prob" nas regras do firewall, opo
essa, seguida de um nmero entre 0 e 1, o qual corresponde probabilidade estatstica dos pacotes que
sero liberados pelo firewall. Dessa forma, uma probabilidade 0.9 (indicada pelo comando "prob 0.9") vai
permitir o trfego de 90% dos pacotes que passaram por aquela regra, da mesma forma que uma "prob
0.1" permitir apenas 10% de probabilidade. Segue ento uma pequena extenso da sintaxe do ipfw(8)
que ns estvamos acostumados:

<comando> [<no. regra>] [prob <prob_ocorrencia>] <aco> [log [logamount
<nmero>]]
<proto>from <origem>to <destino>[<interface-spec>] [<opcoes>]

Por exemplo, se ns quisermos restringir 20% dos pedidos de echo (echo requests) do ICMP,
poderamos usar a seguinte regra:

add 1000 prob 0.8 allow icmp from any to any in icmptypes 8

Podemos tambm querer negar 50% dos pacotes TCP SYN pro servidor web, dessa forma
simulando um trfego pesado na interface ep0. Faramos da seguinte forma:

add 1000 prob 0.5 allow tcp from any to any in setup via ep0

A utilizao de probabilidade de ocorrncias uma funo nativa do ipfirewall(4).

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
8. Fluxo do Trfego pelo Firewall.
Vamos lembrar que as regras que no especificam se o pacote deve ser examinado na entrada ou
sada pelo firewall (usando as opes "in" e "out"), sero sempre verificadas pro trfego de entrada *E*
de sada. Isso implica em algumas consequncias. Quando uma regra redireciona o trfego pra um tnel
sem usar "in" ou "out", a regra ser duplicada, um tnel pros pacotes que saem e um pros que entram.
Outra coisinha, quando as regras no so definidas por interface (usando "via") todas as regras so
aplicadas todas as interfaces, mesmo se definidos entrada e sada ("in", "out"), simplesmente porque,
imagine seu gateway com mltiplas interfaces de rede, uma pra rede verdadeira (Internet) e duas pra redes
internas. Todo trfego definido como "in" o que entra pelas interfaces pra mquina firewall, ou seja, se
vem da internet pro gateway, ENTRA pelo firewall; Se vem das redes locais pro gateway, ENTRA pelo
firewall.
Devemos tambm notar os conceitos de half-duplex e de full-duplex pras conexes. Se o trfego
de entrada e sada so direcionaos pro mesmo tnel, ento ele vai adotar um coportamento half-duplex,
simplesmente porque o tnel no pode rotear o trfego em ambas as direes ao mesmo tempo. Se voc
esta trabalhando com conexes de rede que sejam full-duplex portanto sempre recomendado criar tneis
distintos, pro trfego que entra e pro que sai, dessa forma podendo rotear as duas direes ao mesmo
tempo. Eis a segunda razo que ns estvamos devendo pra se ter duas regras, uma pra controlar cada
direo de fluxo.
31
Apndice A: Exemplos de Configuraes de Firewall
Vamos ilustrar aqui alguns cenrios onde necessrio implementar um firewall. Cada um
exemplificado com regras de firewall e uma explicao breve de como a regra funciona. Nos nossos
exemplos vamos adotar a rede 12.18.123.0/24 como a local, xl0 ser a interface de rede externa e xl1 ser
a interna.
P) Como eu bloqueio pings externos, mas permito que eu possa pingar qualquer estao externa?
R) A soluo Stateful. As regras dinmicas pros pacotes ICMP usam as definioes do
net.inet.ip.fw.dyn_short_lifetime no sysctl(8), que de 5 segundos de vida pra cada regra. A vantagem da
soluo Stateful que as respostas de echo so permitidas apenas das mquinas que voc pingou.

add 1000 deny icmp from any to 12.18.123.0/24 in via xl0 icmptypes 8
add 1010 check-state
add 1020 allow icmp from 12.18.123.0/24 to any out via xl0 icmptypes 8 keep-state
add 1030 deny icmp from any to any

O motivo pra regra de negao antes da regra com check-state que as regras dinmicas so bi-
direcionais, ou seja, os pedidos de echo podem vir de estaes externas que sero permitidos, durante a
vida ltil da regra. Por isso filtramos os pings externos antes de verificarmos as regras dinmicas.
A soluo Stateless. A vantagem que sobrecarrega menos o firewall, porque existe um nmero
menor de regras serem processadas; mas, elas sobrecarregam o firewall quando no existem muitas
ocorrncias de tentativas de pings, ento a vantagem de uma soluo ou outra depende de uma anlise da
frequncia que os pings ocorrem.

add 1000 deny icmp from any to 12.18.123.0/24 in via xl0 icmptypes 8
add 1010 allow icmp from 12.18.123.0/24 to any out via xl0 icmptypes 8
add 1020 allow icmp from any to 12.18.123.0/24 in via xl0 icmtypes 0

Outra desvantagem da soluo Stateless que ela vai sempre aceitar respostas de echo (Echo
Reply) de qualquer estao, enquando a soluo Stateful permite resposta apenas das estaes que foram
pingadas.
P) Como eu bloqueio que as redes privadas, conforme definidas na RFC 1918, sejam roteadas pra
dentro ou pra fora da minha rede?
R)

add 1000 deny all from 192.168.0.0/16 to any via xl0
add 1010 deny all from any to 192.168.0.0/16 via xl0
add 1020 deny all from 172.16.0.0/12 to any via xl0
add 1030 deny all from any to 172.16.0.0/12 via xl0
add 1040 deny all from 10.0.0.0/8 to any via xl0
add 1050 deny all from any to 10.0.0.0/8 via xl0

P) Como eu posso forar a limitao de taxas de cada estao na minha rede de forma individual? Eu
quero forar um limite de UpStream de 64Kbit por segundo e DownStream de 384 Kbit por segundo pra
cada estao; ainda, quero tambm evitar que qualquer estao externa inicie conexes com as estaes
na minha rede, dessa forma ningum vai poder rodar nenhum tipo de servidor.
R) Essa a soluo adotada em uma universidade:

pipe 10 config mask src-ip 0x000000ff bw 64kbit/s queue 8Kbytes
pipe 20 config mask dst-ip 0x000000ff bw 384kbit/s queue 8Kbytes
add 100 deny icmp from any to 12.18.123.0/24 in via xl0 icmptypes 8
add 110 check-state
add 1000 pipe 10 all from 12.18.123.0/24 to any out via xl0
add 1100 pipe 20 all from any to 12.18.123.0/24 in via xl0
add 1200 allow tcp from 12.18.123.0/24 to any out via xl0 setup keep-state
add 1200 allow udp from 12.18.123.0/24 to any out via xl0 keep-state
add 1300 allow icmp from 12.18.123.0/24 to any out icmptypes 8 keep-state
add 65535 deny all from any to any

32