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;
Oleitordestedocumento fortementeindicadoaobtermaisinformaessobreosrecursosacima.As fontesdeinformaorecomendadassoohistricodalistadediscussesFUGBReolivro FreeBSD: PoderparaServir,dePatrickTracanellieJeanM.Melo,estequeporsuavezdocumentatodosostpicos noabordadosaqui,comamplosdetalhes. Estedocumentoest emplenasincroniacomavers o0.4desteHOWTO.Adiferenaentreavers o0.3ea 0.4s ocorreesortogr ficasemlnguainglesa.
Este documento encontrase disponvel no website da FreeBSD Brasil por referncia histrica (especialmentelinksreferenciadosporenginesdebusca).Oenderecopermanentedestedocumentoem suaversooriginal: http://free.bsd.com.br/~eksffa/freebsd/ipfw.txt
Reproduointegralouparcialpermitidadesdequeasfontesoriginaissejammencionadas.
http://www.freebsdbrasil.com.br
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) O /etc/rc.firewall e firewalls com poltica aberta Carregando Rulesets (conjunto de regras) 2.2.1. 2.2.2. 3. Tipos de Firewall pr-definidos Tipos de Firewall Personalizado
2.1. (OPEN firewalls) 2.2.
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. Uma introduo Netmask e Bitmask Especificando Portas e Faixas de Portas
4.
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. icmptypes tcpflags, setup & established ipoptions
Reconhecendo Pacotes Fragmentados Filtragem baeada em UID e GID
5.
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
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. Configurao de log nas regras
Introduo filtragem 'Stateless' e 'Stateful' de pacotes 6.1. 6.2. Configuraes 'Stateful' Iniciais Configuraes 'Stateful' Avanadas 6.3. Anatomia de uma Regra Dinmica
7.
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. http://www.freebsdbrasil.com.br
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: http://www.freebsdbrasil.com.br
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 http://www.freebsdbrasil.com.br
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. http://www.freebsdbrasil.com.br
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_enable="YES" firewall_type="UNKNOWN" Se voc quer simplesmente habilitar o firewall para trabalhar algumas http://www.freebsdbrasil.com.br
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 http://www.freebsdbrasil.com.br
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_enable="YES" firewall_type="/etc/rc.firewall.rules" Dessa forma voc vai poder definir sua prpria configurao de firewall no arquivo /etc/rc.firewall.rules, o qual ser carregado sempre que seu firewall for iniciado. Se voc preferir ainda que seu firewall seja iniciado de forma silenciosa, basta incluir no rc.conf: firewall_quiet="YES" O formato do seu conjunto de regras ser apresentado de forma um pouquinho diferente nesse arquivo, em relao ao que voc encontra no rc.firewall. O motivo simples, o rc.firewall um 'shell script' sh(1) escrito de forma que possa rodar por si prprio, enquanto o arquivo que define as suas regras personalizadas esto ali simplesmente para serem processadas pelo ipfw(8). A principal diferena que voc no vai usar nada correspondente varivel ${fwcmd} usada no rc.firewall. Simplesmente as regras. Posteriormente, vamos construir um arquivo de regras prprio, e ento vamos ver isso passo-a-passo.
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 http://www.freebsdbrasil.com.br
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 http://www.freebsdbrasil.com.br
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 1 IPs Usveis 1
IPFWHOWTO
31 30 29 28 27 26 25 24 ... 22 20 16 12 8.388606+e6 8 (256^3)-2 0 255.255.192.0 255.255.128.0 255.255.0.0 255.128.0.0 255.0.0.0 0.0.0.0 (todos IPs) 256^4 16320 32768 16318 32766 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
65536 8.388608+e6 256^3
65534
(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 http://www.freebsdbrasil.com.br
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 allow tcp from any to 172.16.0.5 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 http://www.freebsdbrasil.com.br
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 8 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, http://www.freebsdbrasil.com.br
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) http://www.freebsdbrasil.com.br
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) http://www.freebsdbrasil.com.br
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 http://www.freebsdbrasil.com.br
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 http://www.freebsdbrasil.com.br
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 http://www.freebsdbrasil.com.br
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 Z
Essa linha pode ser adicionada no final do arquivo newsyslog.conf(5). A primeira entrada um tanto quanto bvia, ela indica qual arquivo vai ser rotacionado. A segunda indica os bits de permisses pros arquivos rotacionados. A terceira parte o nmero de arquivo de logs que se deseja manter rotacionando at que o mais antigo seja apagado. O seguinte o tamanho do arquivo quando ele deve ser rotacionado, no estamos usando essa opo. A quintar parte quando (tempo) ns devemos rotacionar o arquivo, e finalmente a ltima opo, uma opo especial. Como voc j deve ter concludo, rotao de logs so definidas por dois critrios: tamanho ou data. No nosso caso, ns indicamos que queremos que o arquivo de log seja rotacionado s duas da manh de todo domingo, no importando o tamanho do arquivo de log. Depois definimos (a ltima opo especial, Z) que o arquivo deve ser comprimido com gzip(1) sempre que rotacionar, e definimos que vamos manter um histrico arquivado de 10 semanas. Se voc deseja manter seus logs por mais que 10 semanas basta alterar o valor 10 pra qualquer um que voc queira. Ou o ideal, criar uma rotina que faa backup em uma mquina separada (um LogHost) a cada 10 semanas, ou ento gravar seus Logs em CD ou qualquer outra mdia barata e de grande capacidade quando for necessrio. Uma vez configurado, o newsyslog.conf(5) vai cuidar do rotacionamento dos logs do ipfirewall(4). O newsyslog.conf(5) ativado pelo cron(8) do FreeBSD, e por isso no precisa de um Daemon rodando, consequentemente voc no tem que reiniciar nenhum processo. Voc pode criar seu prprio script pra rotacionar logs ou usar de terceiros, com tanto que voc confie. De qualquer forma bom decidir uma maneira de controlar o crescimento dos logs dentro do seu sistema. Lembre-se, no existe nada que o cron(8) e um script no possa fazer nesse caso. 5.3. Configurao de Log nas Regras;
Uma vez que tudo esteja pronto pra utilizar as funes de logs do ipfirewall(4), vamos comear a definir quais regras ns queremos logar quando elas forem filtradas. Existem dois parmetros bsicos pra usarmos em conjunto com nossas regras pra definirmos que queremos logar *aquela* regra. Vejamos: "log" o parmetro mais comum. Toda vez que uma regra que for definida o log for acionada, ento a ao definida (action) por aquela http://www.freebsdbrasil.com.br
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 http://www.freebsdbrasil.com.br
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 http://www.freebsdbrasil.com.br
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
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
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 1000 check-state add 2000 allow tcp from 192.168.0.0/27 to any out setup \ keep-state
Dessa forma s os pacotes TCP SYN que sarem pelo seu firewall podero ser roteados, ou seja, os pedidos que entrarem sero automaticamente negados. Esse o mesmo tipo de proteo que o NAT e proxies transparentes de forma geral oferecem pras mquinas internas. At agora ns trabalhamos essencialmente com regras 'stateful' que manipulavam conexes TCP. claro, no pra menos, conexes TCP representam a grande maioria do trfego gerado em rede, contudo voc se lembra que ns comentamos que o ipfirewall(4) poderia manipular tambm filtragem 'stateful' de outro protocolos. Bom, ento de uma olhada nas regras que ns usamos pra permitir que nossos clientes internos pudessem pingar qualquer mquina pra fora da rede, enquanto ningum poderia nos pingar, quando estudamos a seo referente ao icmptypes. Agora vamos fazer a mesma coisa usando "check-state" e "set-state": add 1000 check-state add 2000 allow icmp from any to any out icmptypes 8 keep-state J podemos entender facilmente essa regra, que cria uma regra dinmica pra cada pedido de echo que nossas estaes internas faam pra fora. Quando a resposta chega ela permitida pela regra dinmica que estabeleceu a conexo entre as duas pontas, e se algum de fora tenta pingar uma mquina interna, a regra padro nega essa ao. O protocolo ICMP usa a varivel net.inet.ip.fw.dyn_short_lifetime do sysctl(8). Se a resposta do ping demorar mais que 5 segundos pra chegar a regra vai ser descarregada e o pacote no vai poder ser roteado. Se voc considera que as respostas de ping levaro mais que 5 segundos pra acontecer, ento voc, como administrador da rede deve elevar o valor da varivel no sysctl(8). De qualquer forma a maioria dos atrasos de rede levam menos de 1 segundo, a no ser que seja IRC ;-)
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: 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
80
Ns j conhecemos as regras estticas apresentadas, contudo, essa a primeira vez que ns estamos encontrando uma regra dinmica listada pelo nosso firewall. Vamos examina-la com mais ateno: A primeira citao de uma regra dinmica o nmero da regra esttica que a gerou, no nosso caso, a regra nmero 2000, que tem a opo keep-state ajustada, conforme aprendemos anteriormente. A segunda parte o nmero de vezes que aquela regra foi utilizada, ou seja o nmero de vezes que um pacote saiu pelo firewall atravs daquela regra, ou o nmero de incidncias da regra, seguido do nmero total de bytes que os pacotes que passaram por aquela regra rotearam. Entre parnteses encontramos o valor T que indica o timeout (o tempo de vida) daquela regra, em segundos. Nesse caso ainda existem 54 segundos de vida para essa regra. A cerquilha (#) indica o nmero da regra, nesse caso essa a nossa regra nmero 0. O 'ty 0' indica o tipo de regra dinmica em questo. Os tipos de regras correspondem ao fluxo do roteamento de pacotes atravs daquela regra, ou seja, se ela permite apenas trfego da origem pro destino, do destino pra origem, ou se a regra bidirecional. No nosso caso temos apenas um tipo indicado, que o padro: bidirecional. Podemos verificar essa afirmao visualmente, indicado pelo smbolo <-> entre a Porta/IP de origem e de destino. Depois do tipo da regra dinmica podemos constatar o protocolo que a regra ta usando, seguidos do IP/porta de origem, o smbolo de fluxo dos pacotes (no caso <->) e finalmente o IP/porta do destino da conexo. Mesmos depois que uma regra dinmica foi descarregada, voc ainda pode lista-la com o comando ipfw list, contudo a regra inativa vai ter um valor de tempo de vida (T) igual a zero (T 0, #). Uma vez descarregada, a regra no vai mais aceitar pacotes, simplesmente porque ela no existe mais, at que a mesma regra seja reiniciada, ou ressucitada pela mesma entrada keep-state da regra que a originou inicialmente. Uma vez descarregadas, as regras tambm podem ser substitudas por novas regras dinmicamente ativadas. A no ser que todas as regras dinmicas continuem em pleno uso, elas sero continuamente substitudas por novas regras, especialmente se o nmero de regras dinmicas alcanou o mximo permitido pelas variveis do sysctl(8). http://www.freebsdbrasil.com.br
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 http://www.freebsdbrasil.com.br
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 http://www.freebsdbrasil.com.br
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 http://www.freebsdbrasil.com.br
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 http://www.freebsdbrasil.com.br
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 http://www.freebsdbrasil.com.br
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

2.1. (OPEN firewalls) 2.2.

Reconhecendo Pacotes Fragmentados Filtragem baeada em UID e GID

Reinjection) 8. Fluxo do Trfego pelo Firewall

Apndice A: Exemplos de Configuraes de Firewall;

Informacoes gerais sobre a Filtragem de Pacotes de Rede;

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

Carregando Rulesets (conjunto de regras);

Sintaxe de regras bsicas do Ipfw(8);

65536 8.388608+e6 256^3

Controle de Interface e Fluxo;

Voc ainda pode habilitar a seguinte opo: options IPFIREWALL_VERBOSE_LIMIT=#

Ns j mencionamos essas opes anteriormente, quando estavamos revendo http://www.freebsdbrasil.com.br

Configuraes 'Stateful' Iniciais;

Você também pode gostar