Escolar Documentos
Profissional Documentos
Cultura Documentos
Ipfw Howto
Ipfw Howto
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
http://www.freebsdbrasil.com.br
Reproduointegralouparcialpermitidadesdequeasfontesoriginaissejammencionadas.
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.
2.1.
(OPEN firewalls)
2.2.
3.
4.
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.
icmptypes
tcpflags, setup & established
ipoptions
Logs (Logging)
5.1.
5.2.
Propriedades de Logs
Configuraes de Logs do sistema
5.2.1. Opes do Kernel
http://www.freebsdbrasil.com.br
Reproduointegralouparcialpermitidadesdequeasfontesoriginaissejammencionadas.
IPFWHOWTO
7.
7.1.
Probabilidade de Ocorrncias (Probability Matching)
Dummynet
7.2.1.
7.2.2.
7.2.3.
Reinjection)
8.
1.
Reproduointegralouparcialpermitidadesdequeasfontesoriginaissejammencionadas.
IPFWHOWTO
2.
Acionando o Ipfirewall(4);
IPFIREWALL
Reproduointegralouparcialpermitidadesdequeasfontesoriginaissejammencionadas.
IPFWHOWTO
IPFIREWALL_DEFAULT_TO_ACCEPT
Reproduointegralouparcialpermitidadesdequeasfontesoriginaissejammencionadas.
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=#
IPV6FIREWALL
IPV6FIREWALL_VERBOSE
IPV6FIREWALL_VERBOSE_LIMIT=100
IPV6FIREWALL_DEFAULT_TO_ACCEPT
Reproduointegralouparcialpermitidadesdequeasfontesoriginaissejammencionadas.
IPFWHOWTO
2.1.
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_enable="YES"
firewall_type="UNKNOWN"
Se voc quer simplesmente habilitar o firewall para trabalhar algumas
http://www.freebsdbrasil.com.br
Reproduointegralouparcialpermitidadesdequeasfontesoriginaissejammencionadas.
IPFWHOWTO
2.2.
Reproduointegralouparcialpermitidadesdequeasfontesoriginaissejammencionadas.
IPFWHOWTO
3.
http://www.freebsdbrasil.com.br
Reproduointegralouparcialpermitidadesdequeasfontesoriginaissejammencionadas.
IPFWHOWTO
http://www.freebsdbrasil.com.br
Reproduointegralouparcialpermitidadesdequeasfontesoriginaissejammencionadas.
IPFWHOWTO
Reproduointegralouparcialpermitidadesdequeasfontesoriginaissejammencionadas.
IPFWHOWTO
http://www.freebsdbrasil.com.br
Reproduointegralouparcialpermitidadesdequeasfontesoriginaissejammencionadas.
IPFWHOWTO
Especificando Protocolos;
Reproduointegralouparcialpermitidadesdequeasfontesoriginaissejammencionadas.
IPFWHOWTO
Total de Ips
255.255.255.255
IPs Usveis
1
http://www.freebsdbrasil.com.br
Reproduointegralouparcialpermitidadesdequeasfontesoriginaissejammencionadas.
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
Reproduointegralouparcialpermitidadesdequeasfontesoriginaissejammencionadas.
IPFWHOWTO
sempre.
3.4.2.
1000
1100
1200
1300
25
1021-1023
21,22,23
1024:8
Reproduointegralouparcialpermitidadesdequeasfontesoriginaissejammencionadas.
IPFWHOWTO
A ao "unreach";
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
Reproduointegralouparcialpermitidadesdequeasfontesoriginaissejammencionadas.
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"
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.
Reproduointegralouparcialpermitidadesdequeasfontesoriginaissejammencionadas.
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.
Reproduointegralouparcialpermitidadesdequeasfontesoriginaissejammencionadas.
IPFWHOWTO
urg
urgentes)
A <flag> SYN a mais interessante, visto que ela enviada quando uma
conexo TCP iniciada. Por ser to importante, existe inclusive uma opo
separada do ipfw(8) dedicada especialmente pra definir pacotes TCP cujo
cabealho tenha a flag SYN ajustada. Essa opo se chama "setup". claro que
s podemos trabalhar com a opo "setup" quando o protocolo indicado o "tcp".
"setup" - Qualquer regra contendo essa opo vai filtrar todos os
pacotes TCP cujo cabealho indique a flag SYN ajustada. Dessa forma, se
quizermos simplesmente negar todos os pacotes TCP que estiverem entrando no
firewall com o cabealho SYN definido, temos duas opes:
add deny tcp from any to any in tcpflags syn
OU SIMPLESMENTE:
add deny tcp from any to any in setup
Em cada uma dessas regras, a mesma ao tomada: todos os pacotes TCP
SYN vindos de qualquer (any) origem para qualquer (any) destino sero negados.
Vale a pena ilustrarmos a necessidade do protocolo ser "tcp" quando
trabalharmos essas regras.
"established" - Exatamente como existe uma opo especial que
identifica um pedido de inicializao de conexo TCP ("setup"), existe tambm
uma opo que identifica quando uma conexo j est estabelecida, ou seja, ja
foi iniciada. Pela grande importncia de facilitar o controle de conexes TCP,
as opes "established" e "setup" foram disponibilizadas, dessa forma
oferecendo facilidade na criao de regras. Utilizando estas opes (ou mesmo
suas definies nativas correspondentes s "tcpflags") podemos ter inicialmente
um controle de conexes TCP mais simples. Essa a base de implementaes
"stateful" de um firewall. Vamos trabalhar com elas de forma mais detalhada
depois.
4.3.3.
ipoptions;
Reproduointegralouparcialpermitidadesdequeasfontesoriginaissejammencionadas.
IPFWHOWTO
Reproduointegralouparcialpermitidadesdequeasfontesoriginaissejammencionadas.
IPFWHOWTO
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.
IPFIREWALL_VERBOSE
IPFIREWALL_VERBOSE_LIMIT=#
Reproduointegralouparcialpermitidadesdequeasfontesoriginaissejammencionadas.
IPFWHOWTO
IPFIREWALL_VERBOSE_LIMIT=10
/var/log/ipfw/ipfw.log
http://www.freebsdbrasil.com.br
Reproduointegralouparcialpermitidadesdequeasfontesoriginaissejammencionadas.
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
root
root
root
*
http://www.freebsdbrasil.com.br
Reproduointegralouparcialpermitidadesdequeasfontesoriginaissejammencionadas.
IPFWHOWTO
600
10
$W0D2
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
http://www.freebsdbrasil.com.br
Reproduointegralouparcialpermitidadesdequeasfontesoriginaissejammencionadas.
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
-
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.
Reproduointegralouparcialpermitidadesdequeasfontesoriginaissejammencionadas.
IPFWHOWTO
http://www.freebsdbrasil.com.br
Reproduointegralouparcialpermitidadesdequeasfontesoriginaissejammencionadas.
IPFWHOWTO
6.1.
1000
2000
3000
3100
allow
allow
allow
allow
tcp
tcp
udp
udp
from
from
from
from
http://www.freebsdbrasil.com.br
Reproduointegralouparcialpermitidadesdequeasfontesoriginaissejammencionadas.
IPFWHOWTO
http://www.freebsdbrasil.com.br
Reproduointegralouparcialpermitidadesdequeasfontesoriginaissejammencionadas.
IPFWHOWTO
Protocolo
Endereo & Porta IP
Destino & Porta IP
Tempo da regra esgotado
Reproduointegralouparcialpermitidadesdequeasfontesoriginaissejammencionadas.
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
http://www.freebsdbrasil.com.br
Reproduointegralouparcialpermitidadesdequeasfontesoriginaissejammencionadas.
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
http://www.freebsdbrasil.com.br
Reproduointegralouparcialpermitidadesdequeasfontesoriginaissejammencionadas.
IPFWHOWTO
Dessa forma s os pacotes TCP SYN que sarem pelo seu firewall podero
ser roteados, ou seja, os pedidos que entrarem sero automaticamente negados.
Esse o mesmo tipo de proteo que o NAT e proxies transparentes de forma
geral oferecem pras mquinas internas.
At agora ns trabalhamos essencialmente com regras 'stateful' que
manipulavam conexes TCP. claro, no pra menos, conexes TCP representam a
grande maioria do trfego gerado em rede, contudo voc se lembra que ns
comentamos que o ipfirewall(4) poderia manipular tambm filtragem 'stateful' de
outro protocolos. Bom, ento de uma olhada nas regras que ns usamos pra
permitir que nossos clientes internos pudessem pingar qualquer mquina pra fora
da rede, enquanto ningum poderia nos pingar, quando estudamos a seo
referente ao icmptypes. Agora vamos fazer a mesma coisa usando "check-state"
e "set-state":
add 1000 check-state
add 2000 allow icmp from any to any out icmptypes 8 keep-state
J podemos entender facilmente essa regra, que cria uma regra dinmica
pra cada pedido de echo que nossas estaes internas faam pra fora. Quando a
resposta chega ela permitida pela regra dinmica que estabeleceu a conexo
entre as duas pontas, e se algum de fora tenta pingar uma mquina interna, a
regra padro nega essa ao. O protocolo ICMP usa a varivel
net.inet.ip.fw.dyn_short_lifetime do sysctl(8). Se a resposta do ping demorar
mais que 5 segundos pra chegar a regra vai ser descarregada e o pacote no vai
poder ser roteado. Se voc considera que as respostas de ping levaro mais que
5 segundos pra acontecer, ento voc, como administrador da rede deve elevar o
valor da varivel no sysctl(8). De qualquer forma a maioria dos atrasos de rede
levam menos de 1 segundo, a no ser que seja IRC ;-)
http://www.freebsdbrasil.com.br
Reproduointegralouparcialpermitidadesdequeasfontesoriginaissejammencionadas.
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.
Vamos dar uma olhada na sada que voc devei encontrar quando listar as
regras dinmicas de um firewall 'stateful' no seu FreeBSD:
80
Reproduointegralouparcialpermitidadesdequeasfontesoriginaissejammencionadas.
IPFWHOWTO
http://www.freebsdbrasil.com.br
Reproduointegralouparcialpermitidadesdequeasfontesoriginaissejammencionadas.
IPFWHOWTO
Dummynet;
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
http://www.freebsdbrasil.com.br
Reproduointegralouparcialpermitidadesdequeasfontesoriginaissejammencionadas.
IPFWHOWTO
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.
Reproduointegralouparcialpermitidadesdequeasfontesoriginaissejammencionadas.
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.
Reproduointegralouparcialpermitidadesdequeasfontesoriginaissejammencionadas.
IPFWHOWTO
Reproduointegralouparcialpermitidadesdequeasfontesoriginaissejammencionadas.
IPFWHOWTO
|
REDE INTERNA <==
REDE INTERNA ==>
(OUT) |
(IN) |
http://www.freebsdbrasil.com.br
Reproduointegralouparcialpermitidadesdequeasfontesoriginaissejammencionadas.
IPFWHOWTO
Reproduointegralouparcialpermitidadesdequeasfontesoriginaissejammencionadas.
IPFWHOWTO
1000
1010
1020
1030
1040
1050
deny
deny
deny
deny
deny
deny
all
all
all
all
all
all
from
from
from
from
from
from
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
http://www.freebsdbrasil.com.br
Reproduointegralouparcialpermitidadesdequeasfontesoriginaissejammencionadas.