Ipfw Howto

IPFWHOWTO
Ateno: este documento apesar de datado, ainda considerado prtico, e a melhor introduo ao
IPFIREWALL(4)disponvelpublicamentenaInternet.Todasasinformaesaquidisponveiscontinuam
vlidaseaplicveisnasversesmaisrecentesdoFreeBSD.Contudo,umasriederecursosnoso
documentadosnestedocumento,asaber:
ControledeBandaeQoScomWF2Q+
;SuporteALTQ;
BlocosOR;
Tabelaseanlisebinriaavanada;
GruposdeRegras;
MarcaodePacotes;
FiltrodeCamada2;
FiltrodeCamada7emconjuntocomNetgraph;
BalanceamentoeRedundnciadeFirewall(IPFWTEE);
Recursosantispoofnativos;
FiltroIPv6;
Outrosdemenorrelevncia;
Oleitordestedocumentofortementeindicadoaobtermaisinformaessobreosrecursosacima.As
fontesdeinformaorecomendadassoohistricodalistadediscussesFUGBReolivro FreeBSD:
PoderparaServir,dePatrickTracanellieJeanM.Melo,estequeporsuavezdocumentatodosostpicos
noabordadosaqui,comamplosdetalhes.
Estedocumentoestemplenasincroniacomaverso0.4desteHOWTO.Adiferenaentreaverso0.3ea
0.4socorreesortogrficasemlnguainglesa.
Este documento encontrase disponvel no website da FreeBSD Brasil por referncia histrica
(especialmentelinksreferenciadosporenginesdebusca).Oenderecopermanentedestedocumentoem
suaversooriginal:
http://free.bsd.com.br/~eksffa/freebsd/ipfw.txt
http://www.freebsdbrasil.com.br
Reproduointegralouparcialpermitidadesdequeasfontesoriginaissejammencionadas.
IPFWHOWTO
IPFWHOWTO
V.0.3br_pt
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@freebsdbrasil.com.br) e Maurcio Goto (freebsdbrasil@uol.com.br). A verso mais recente do mesmo estar sempre disponvel em
http://free.bsd.com.br/~eksffa/freebsd/ipfw.txt
Sumrio.
1.
2.
Informacoes gerais sobre a Filtragem de Pacotes de Rede

Acionando o Ipfirewall(4)
2.1.
(OPEN firewalls)
2.2.
O /etc/rc.firewall e firewalls com poltica aberta

Carregando Rulesets (conjunto de regras)
2.2.1.
2.2.2.
3.
Sintaxe de regras bsicas do Ipfw(8)

3.1.
3.2.
3.3.
3.4.
Listando Regras Ativas

Comandos bsicos e suas funes
Especificando Protocolos
Especificando endereos de Origem e de Destino
3.4.1.
3.4.2.
4.
Uma introduo Netmask e Bitmask

Especificando Portas e Faixas de Portas
Sintaxe de regras avanadas do ipfw(8)

4.1.
4.2.
4.3.
A ao "unreach"
Controle de Interface e de Fluxo
Combinando tipos de pacotes ICMP e TCP especficos
4.3.1.
4.3.2.
4.3.3.
4.4.
4.5.
5.
Tipos de Firewall pr-definidos

Tipos de Firewall Personalizado
icmptypes
tcpflags, setup & established
ipoptions
Reconhecendo Pacotes Fragmentados

Filtragem baeada em UID e GID
Logs (Logging)
5.1.
5.2.
Propriedades de Logs
Configuraes de Logs do sistema
5.2.1. Opes do Kernel
IPFWHOWTO
5.2.2. Configurando o syslog(8)

5.2.3. Configurao do newsyslog(8) pra fazer
rotacionamento de logs (log rotation)
5.3.
6.
Introduo filtragem 'Stateless' e 'Stateful' de pacotes

6.1.
6.2.
7.
Configurao de log nas regras
Configuraes 'Stateful' Iniciais

Configuraes 'Stateful' Avanadas
6.3.
Anatomia de uma Regra Dinmica
Traffic Shapping (controle de trfego)

7.2.
7.1.
Probabilidade de Ocorrncias (Probability Matching)
Dummynet
7.2.1.
7.2.2.
7.2.3.
Enfileiramento de pipes (Pipe Queues)

Mscaras de pipes (Pipe Masks)
Remanejamento de pacotes por pipes (Packet
Reinjection)
8.
Fluxo do Trfego pelo Firewall
Apndice A: Exemplos de Configuraes de Firewall;
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.
IPFWHOWTO
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.
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:
IPFWHOWTO
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
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
IPFWHOWTO
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
options
options
IPFIREWALL_VERBOSE
IPFIREWALL_FORWARD
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 aborda-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
options
options
options
IPV6FIREWALL
IPV6FIREWALL_VERBOSE
IPV6FIREWALL_VERBOSE_LIMIT=100
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.
IPFWHOWTO
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):
${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_type="UNKNOWN"
Se voc quer simplesmente habilitar o firewall para trabalhar algumas
IPFWHOWTO
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 pro nosso capulo 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:
"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
IPFWHOWTO
permitindo a entrada de nenhum pacote que tenha um endereo de retorno igual ao

endereo de qualquer host dentro da rede interna. Vai bloquear todos os pacotes
endereados como de redes privadas, conforme definido na RFC 1928, evitando o
trfego pra dentro ou fora da rede, e vai bloquear ainda todas as redes noroteaveis, conforme definido no Internet-Drafts da IETF (disponvel em
http://www.ietf.org/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_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.
3.
Sintaxe de regras bsicas do Ipfw(8);
IPFWHOWTO
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
IPFWHOWTO
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.
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
IPFWHOWTO
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.
"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
IPFWHOWTO
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
IPFWHOWTO
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
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
32
Total de Ips
255.255.255.255
IPs Usveis
1
IPFWHOWTO
31
30
29
28
27
26
25
24
255.255.255.254
255.255.255.252
255.255.255.248
255.255.255.240
255.255.255.224
255.255.255.192
255.255.255.128
255.255.255.0
2
4
8
16
32
64
128
256
1
2
6
14
30
62
126
254
255.255.192.0
255.255.128.0
255.255.0.0
255.128.0.0
16320
32768
16318
32766
...
22
20
16
12
8.388606+e6
8
(256^3)-2
0
255.0.0.0
0.0.0.0 (todos IPs)
65536
8.388608+e6
65534
256^3
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:
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
IPFWHOWTO
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
add
add
add
1000
1100
1200
1300
allow tcp from any to 172.16.0.5

deny udp from any to 192.168.0.5
25
1021-1023
21,22,23
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, restandonos 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.
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
IPFWHOWTO
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
host
protocol
port
needfrag
srcfail
net-unknown
host-unknown 7
isolated
4.2.
0
1
2
3
4
5
6
net-prohib
host-prohib
tosnet
toshost
12
filter-prohib
host-precedence 14
precedence-cutoff
9
10
11
13
15
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,
IPFWHOWTO
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 quaisqueres, 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:
add 1200 allow all from any to any out via any
Voc vai notar que, quando
entradas que estiverem usando "in"
apresentaro a utilizao do "via"
dependendo da definio de um "in"
voc listar as regras de firewall, as

ou "out" combinadas com "via", no
mas apresentar a citao "recv" ou "xmit",
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
3
4
Echo Reply (Resposta de Echo)

Destination Unreachable (Destino Indisponvel)
Source Quench (Origem extinta)
IPFWHOWTO
5
8
9
10
11
12
13
14
15
16
17
18
Redirect (Redireo)
Echo Request (Pedido de Echo)
Router Advertisement (SPAM de roteamento? :-))
Router Solicitation (Pedido de Roteamento)
Time-to-Live Exceeded (TTL Excedido)
IP header bad (Cabealho IP malformado)
Timestamp Request (Pedido de Timestamp)
Timestamp Reply (Resposta de Timestamp)
Information Request (Pedido de Informao)
Information Reply (Resposta de Informao)
Address Mask Request (Pedido de Mscara de Rede)
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 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)
IPFWHOWTO
urg
urgentes)
Indicate Urgent OOB data (indica um OOB de dados
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
IPFWHOWTO
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 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
IPFWHOWTO
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.
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

IPFWHOWTO
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:
Jan 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.
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
IPFWHOWTO
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
*.notice;news.err
*.alert
*.emerg
root
root
root
*
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~#
IPFWHOWTO
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.
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
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
IPFWHOWTO
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.
so:
Sempre que uma regra logada, as informaes geradas pra tal pacote
-
Data & Hora

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
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
IPFWHOWTO
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).
IPFWHOWTO
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 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
add
add
add
1000
2000
3000
3100
allow
allow
allow
allow
tcp
tcp
udp
udp
from
from
from
from
any to any established

any to 172.16.0.0/27 21,22,25 setup
172.16.0.0/27 to any 53
any 53 to 172.16.0.0/27
IPFWHOWTO
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 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.
IPFWHOWTO
"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
IPFWHOWTO
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 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
IPFWHOWTO
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.
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
IPFWHOWTO
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 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 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 ;-)
IPFWHOWTO
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:
80
00100 allow ip from any to any via lo0

00200 deny ip from any to 127.0.0.0/8
01000 check-state
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
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).
IPFWHOWTO
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
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.
IPFWHOWTO
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
IPFWHOWTO
<pipe #> no ipfw(8). Vamos ento criar um tnel simples:

pipe 10 config bw 100Kbit/s
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
informaes pra uma velocidade mxima de 100 Kilobits
vrias maneiras distintas de indicarmos as medidas de
bit/s, Byte/s, Kbit/s, Kbyte/s, Mbit/s, Mbyte/s. Cada
banda deve usar a opo bw (de bandwidth banda).
limitar o fluxo de
por segundo. Existem
velocidade de trfego:
tnel de limitao de
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
IPFWHOWTO
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
... 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
IPFWHOWTO
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 que sua aplicao definida de forma reversa, se comparadas. Quando
ns utilizamos 'netmask' ns estamos dividindo a rede em subgrupos, de forma
IPFWHOWTO
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 ;-)
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. Uma breve ilustrao:
_________
|
|
REDE INTERNA <==
REDE INTERNA ==>
(OUT) |
(IN) |
| (IN) <== INTERNET

| (OUT) ==> INTERNET
| ________ |
firewall
IPFWHOWTO
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 raso que
ns estvemos devendo pra se ter duas regras, uma pra controlar cada direo de
fluxo.
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
add
add
keep-state
add
1000 deny icmp from any to 12.18.123.0/24 in via xl0 icmptypes 8

1010 check-state
1020 allow icmp from 12.18.123.0/24 to any out via xl0 icmptypes 8
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
IPFWHOWTO
1918, sejam roteadas pra dentro ou pra fora da minha rede?

R)
add
add
add
add
add
add
1000
1010
1020
1030
1040
1050
deny
deny
deny
deny
deny
deny
all
all
all
all
all
all
from
from
from
from
from
from
192.168.0.0/16 to any via xl0

any to 192.168.0.0/16 via xl0
172.16.0.0/12 to any via xl0
any to 172.16.0.0/12 via xl0
10.0.0.0/8 to any via xl0
any to 10.0.0.0/8 via xl0
O) 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 keepstate
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 keepadd 65535 deny all from any to any

Ipfw Howto

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Ipfw Howto

Enviado por

Direitos autorais:

Formatos disponíveis

IPFWHOWTO

Informacoes gerais sobre a Filtragem de Pacotes de Rede

O /etc/rc.firewall e firewalls com poltica aberta

Sintaxe de regras bsicas do Ipfw(8)

Listando Regras Ativas

Uma introduo Netmask e Bitmask

Sintaxe de regras avanadas do ipfw(8)

Tipos de Firewall pr-definidos

Reconhecendo Pacotes Fragmentados

5.2.2. Configurando o syslog(8)

Introduo filtragem 'Stateless' e 'Stateful' de pacotes

Configurao de log nas regras

Configuraes 'Stateful' Iniciais

Traffic Shapping (controle de trfego)

Enfileiramento de pipes (Pipe Queues)

Fluxo do Trfego pelo Firewall

Apndice A: Exemplos de Configuraes de Firewall;

Informacoes gerais sobre a Filtragem de Pacotes de Rede;

IPFW(8), a interface de comando do IPFIREWALL(4) o utilitrio mais

Um firewall costuma ser arquitetado de diversas formas, mas todas as

O ipfirewall(4) pode ser iniciado de duas formas: voc pode adicionar

Em seguida a compilao e instalao acionaria o ipfirewall(4) esttico

root@eeviac~# kldload ipfw && \

Nesse caso, as opes que ns adicionamos no rc.conf anteriormente no

A opo IPFIREWALL_VERBOSE permite logar o trfego de pacotes com o

Pra habilitar as mesmas opes do ipfirewall(4) sem recompilar o seu

O /etc/rc.firewall e firewalls com poltica aberta (OPEN firewalls);

regras e ver como o ipfirewall(4) do FreeBSD funciona, ou ainda, apenas

Carregando Rulesets (conjunto de regras);

Existem duas opes distintas em relao um comjunto de regras pro

Tipos de Firewall pr-definidos;

bvio que a deciso final a do administrador da rede, ou do

permitindo a entrada de nenhum pacote que tenha um endereo de retorno igual ao

Tipos de Firewall Personalizado;

Se voc decidiu estabelecer um conjunto de regras customizado, ento

Sintaxe de regras bsicas do Ipfw(8);

A sintaxe das regras de firewall no FreeBSD so simples. Qualquer regra

Listando Regras Ativas;

A forma mais simples possvel de se listar as regras ativas no

Os dois comandos vo apresentar as mesmas informaes, dispostas da

Comandos bsicos e suas funes;

A partir de agora ns vamos, gradualmente, analisarmos cada opo e

pacote, e se a penltima regra a de nmero 65000, definida pelo rc.firewall

Essa (primeira) regra incrementa o nmero de vezes que um pacote passou

Protocolo (proto) em "protocolo" na sintaxe bsica de uso do ipfw(8),

Especificando endereos de Origem e de Destino;

O endereo de destino e de origem de um pacote tem o mesmo formato em

firewall, o processamento pra aquele pacote termina, e o pacote permitido ou

Uma introduo Netmask e Bitmask;

O princpio bsico que envolve mscaras de rede e bits de rede (netmask

Como voc pode ver existe um padro definido. O nmero de endereo

Especificando Portas e Faixas de Portas;

Voc pode tambm controlar o trfego de conexes baseando-se em

allow tcp from any to 172.16.0.5

Na primeira regra, todos os pacotes TCP cujo destino a porta 25 da

Sintaxe de regras avanadas do ipfw(8);

Embora o overview anterior sobre as criaes de regras do ipfw(8) seja

trfego. Ento, vamos expandir o modelo de sintaxe que estvamos trabalhando no

Primeiramente, vamos introduzir uma nova "ao":

Controle de Interface e Fluxo;

Uma das mais importantes funcionalidades do ipfw(8), que no foi

voc listar as regras de firewall, as

Combinando tipos de pacotes ICMP e TCP especficos;

Pacotes ICMP, TCP e IP so apresentados em vrios formatos distintos.

As linhas .err e .notice iro logar mensagens do kernel e tambm as