IPFW­HOWTO

  Atenção:  este  documento  apesar  de  datado,  é  ainda  considerado  prático,  e  a  melhor  introdução  ao  IPFIREWALL(4) disponível publicamente na Internet. Todas as informações aqui disponíveis continuam  válidas e aplicáveis nas versões mais recentes do FreeBSD. Contudo, uma série de recursos não são  documentados neste documento, a saber:
• • • • • • • • • • • •

Controle de Banda e QoS com WF2Q+ ;Suporte ALTQ; Blocos OR; Tabelas e análise binária avançada; Grupos de Regras; Marcação de Pacotes; Filtro de Camada 2; Filtro de Camada 7 em conjunto com Netgraph; Balanceamento e Redundância de Firewall (IPFW TEE); Recursos anti­spoof nativos; Filtro IPv6; Outros de menor relevância;

O leitor deste documento é fortemente indicado a obter mais informações sobre os recursos acima. As  fontes de informação recomendadas são o histórico da lista de discussões FUG­BR e o livro  FreeBSD:  Poder para Servir, de Patrick Tracanelli e Jean M. Melo, este que por sua vez documenta todos os tópicos  não abordados aqui, com amplos detalhes. Este documento está em plena sincronia com a versão 0.4 deste HOW­TO. A diferença entre a versão 0.3 e a   0.4 são correções ortográficas em língua inglesa.

Este   documento   encontra­se   disponível   no  website  da   FreeBSD   Brasil   por   referência   histórica  (especialmente links referenciados por engines de busca). O endereco permanente deste documento em  sua versão original é: http://free.bsd.com.br/~eksffa/freebsd/ipfw.txt

Reprodução integral ou parcial permitida desde que as fontes originais sejam mencionadas.

http://www.freebsdbrasil.com.br

IPFW­HOWTO
 

Reprodução integral ou parcial permitida desde que as fontes originais sejam mencionadas.

http://www.freebsdbrasil.com.br

IPFW­HOWTO
 

V.0.3br_pt
Se existirem perguntas ou comentários, por favor, envie-os para walt@erudition.net. A versão mais recente desse documento vai estar sempre disponível em www.freebsd-howto.com. Os direitos de reprodução desse documento são reservados. Versão em português desse documento sob responsabilidade de Patrick Tracanelli (eksffa@freebsdbrasil.com.br) e Maurício Goto (freebsdbrasil@uol.com.br). A versão mais recente do mesmo estará sempre disponível em http://free.bsd.com.br/~eksffa/freebsd/ipfw.txt Sumário. 1. 2. Informacoes gerais sobre a Filtragem de Pacotes de Rede Acionando o Ipfirewall(4) O /etc/rc.firewall e firewalls com política 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 básicas do Ipfw(8) 3.1. 3.2. 3.3. 3.4. Listando Regras Ativas Comandos básicos e suas funções Especificando Protocolos Especificando endereços de Origem e de Destino 3.4.1. 3.4.2. Uma introdução à Netmask e Bitmask Especificando Portas e Faixas de Portas

4.

Sintaxe de regras avançadas do ipfw(8) 4.1. 4.2. 4.3. A ação "unreach" Controle de Interface e de Fluxo Combinando tipos de pacotes ICMP e TCP específicos 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 Configurações de Logs do sistema 5.2.1. Opções do Kernel http://www.freebsdbrasil.com.br

Reprodução integral ou parcial permitida desde que as fontes originais sejam mencionadas.

IPFW­HOWTO
  5.2.2. Configurando o syslog(8) 5.2.3. Configuração do newsyslog(8) pra fazer rotacionamento de logs (log rotation) 5.3. 6. Configuração de log nas regras

Introdução à filtragem 'Stateless' e 'Stateful' de pacotes 6.1. 6.2. Configurações 'Stateful' Iniciais Configurações 'Stateful' Avançadas 6.3. Anatomia de uma Regra Dinâmica

7.

Traffic Shapping (controle de tráfego) 7.2. 7.1. Probabilidade de Ocorrências (Probability Matching) Dummynet 7.2.1. 7.2.2. 7.2.3. Enfileiramento de pipes (Pipe Queues) Máscaras de pipes (Pipe Masks) Remanejamento de pacotes por pipes (Packet

Reinjection) 8. Fluxo do Tráfego pelo Firewall

Apêndice A: Exemplos de Configurações de Firewall;

1.

Informacoes gerais sobre a Filtragem de Pacotes de Rede;

IPFW(8), a interface de comando do IPFIREWALL(4) é o utilitário mais comum e mais popular pra implementar a filtragem de pacotes IP e controle de tráfego de rede no FreeBSD, e é a ferramenta de FIREWALL nativa com a qual o FreeBSD trabalha por padrão (mesmo considerando que, inicialmente o firewall é desabilitado a nível de kernel). A forma lógica como o IPFW trabalha suas regras é parecida com a adotada em muitos outros filtros de pacotes (Packet Filters), com excessão do IPFilter, que opera com um padrão 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 utilização da chave 'quick', necessária para que o ipf(8) não traverse a regra inteira, todas as vezes que ela é lida; entre outros fatores particulares de utilização do IPFilter). Mas isso não tira a qualidade e o poder de implementação de firewalls do ipf(8), que tem também suas próprias vantagens. A escolha final em relação a qual ferramenta de Filtragem de Pacotes utilizar, é uma decisão pessoal, a não ser que você tenha necessidade de alguma característica de um Firewall que o outro não possua, contudo, nós vamos abordar uma comparação 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 conexões, e a partir da série 4.x do FreeBSD (FreeBSD 4.0), o ipfirewall(4) também pode gerenciar uma filtragem por estado (stateful) de conexões mais rudimentares, de acordo com estados de conexão. Esse comportamento é sempre transparente pros usuários, ou seja, ninguém vai notar que existe um firewall presente, até que um evento aguardado seja bloqueado. http://www.freebsdbrasil.com.br

Reprodução integral ou parcial permitida desde que as fontes originais sejam mencionadas.

nenhum pacote será roteado.ko.freebsdbrasil. contudo sua configuração é bem mais trabalhosa. mas todas as maneiras podem ser simplificadas com base em duas políticas de filtragem: aberto e fechado. logo após a próxima inicialização do sistema. a compilação estática proporciona. ou seja. 2. as coisas não são tão simples quanto parecem. e libera um a um o tráfego de conexões permitidas. de qualquer maneira. uma melhor performance. o equivalente seria adicionar a seguinte linha no arquivo de configurações do seu kernel: options IPFIREWALL Em seguida a compilação e instalação acionaria o ipfirewall(4) estático no kernel. É claro que esse tipo de dor de cabeça pode ser evitada. a geração e limitação de logs. vai perceber que existe a necessidade de algumas opções adicionais pra poder usar a estação. Pra carregar o ipfw de forma dinâmica. vai entender porque o uso do equipamento vai se complicar muito. Já o firewall que segue uma política fechada. se você não perceber que o firewall usa uma política padrão fechada. ou você pode usar o kldload(8) pra carregar dinâmicamente o módulo base do ipfw(8). porque você pode facilmente bloquear o tráfego de algum serviço que esteja sendo utilizado na rede. O ipfirewall(4) pode ser iniciado de duas formas: você pode adicionar as opções apropriadas no seu kernel através do seu arquivo de configurações. tanto de forma estática quanto dinâmica. bloqueando todo o roteamento de pacotes. você quiser carregar o ipfirewall(4) de um computador remoto. Se. As duas abordagens funcionam bem pra adicionar um firewall(4) com configurações básicas. Isso fatalmente pode se tornar um tormento se você for adicionar o firewall remotamente. . simplesmente use o comando: root@eeviac~# kldload ipfw root@eeviac~# Pra acionar o ipfirewall(4) de forma estática.br Reprodução integral ou parcial permitida desde que as fontes originais sejam mencionadas.com. que são bem mais difíceis de se prever. então recomendados que se faça da seguinte forma: http://www. Acionando o Ipfirewall(4). Essa segunda implementação proporciona um firewall muito mais rígido. no kernel. mas permite ainda que se adicione opções mais detalhadas de configuração. O Firewall que segue uma política aberta permite que todos os pacotes sejam roteados por padrão. contudo. "abre tudo e bloqueia os indesejados".IPFW­HOWTO   Um firewall costuma ser arquitetado de diversas formas. Alguns protocolos estabelecem conexões dinâmicas. mas você tem como estar atento a esse tipo de situação. faz o inverso. todo o tráfego de rede vai ser bloqueado. Se você prestar atenção nos conceitos de política de firewall citados acima (aberto e fechado). mesmo considerando que não é recomendado acionar o ipfirewall(4) remotamente. ou seja. e compilar um novo kernel pro seu sistema. com pouca diferença. e bloqueia aqueles que pertencem a um tipo de conexão que não é desejado. o ipfw. se você simplesmente seguir os passos descritos acima quando estiver na frente da máquina. Se você simplesmente adicionar o ipfirewall(4) sem nenhuma configuração posterior. Contudo. como por exemplo.

requer um pouco mais de trabalho.conf também é válido se você vai carregar o kernel dinâmicamente. Ainda existe uma alternativa muito boa pra se definir uma política aberta como padrão pro ipfw(8) no kernel. Ainda existem outras opções pro ipfirewall(4) que são possíveis se nós formos acionar o firewall de forma estática no kernel. especialmente se elas estiverem conectadas em rede. ao invés de bloquea-lo.br Reprodução integral ou parcial permitida desde que as fontes originais sejam mencionadas. você não vai conseguir estabelecer uma conexão remota novamente com a máquina.ko automaticamente. ainda que você escolha definir uma política de firewall padrão no kernel. .freebsdbrasil. é recomendável que se carregue o ipfirewall(4) dessa maneira em máquinas locais também. porque essa política já vai ser iniciada por padrão no kernel. as opções que nós adicionamos no rc.conf: firewall_enable="YES" firewall_type="OPEN" Existem ainda outros tipos de firewall previamente definidos no /etc/rc.firewall.conf permite-nos carregar o módulo ipfw. As funções de carregamento do firewall pelo /etc/rc. de forma estátita em uma máquina remota. Então antes de inicializar o sistema com um novo kernel você tem que definir alguma maneira pra máquina aceitar a sua conexão. Pra você fazer isso. pra que assim você não seja bloqueado pelo seu próprio firewall.firewall pra configurar uma política aberta de firewall.firewall pra carregar nossas próprias regras de configurações de firewall. até o início da série 4. porque nós não vamos *precisar* do /etc/rc. mas nós vamos tratar deles posteriormente.conf porque posteriormente nós vamos usar o /etc/rc. ele não vai estar roteando os pacotes. e outra pra definir o tipo de firewall que vai ser iniciado. Então basta adicionar as seguintes entradas no seu /etc/rc. você é obrigado a rebootar a sua máquina. No caso firewall do tipo aberto (OPEN). basta adicionar duas linhas no seu rc. ai sim. contudo.conf. Contudo. Adicionar essas opções ao /etc/rc. uma que vai acionar o firewall na inicialização da máquina.ko não vai ser carregado de forma automática. Contudo se você somente adicionar o ipfirewall(4) no kernel. Você pode simplesmente adicionar a seguinte linha no arquivo de configuração do seu kernel: options IPFIREWALL_DEFAULT_TO_ACCEPT Nesse caso. pra não perder uma conexão em andamento.conf anteriormente não serão *necessárias*. é interessante adicionar aquelas opções ao /etc/rc. O motivo é simples. a partir da próxima inicialização ela irá utilizar o novo kernel. De qualquer forma. ou seja. Acionar o ipfirewall(4) no kernel. evitando assim que você perca a conexão com a máquina remota. Por enquanto vamos começar com uma política de firewall aberta (OPEN). porque se eventualmente seu sistema for reinicializado. o módulo ipfw.x do FreeBSD algumas dessas opções não podiam ser acionadas se não fosse de http://www. assim que o sistema estiver no ar. quando você termina de instalar um novo kernel.IPFW­HOWTO   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 tráfego da rede.com.

fw. mas nas versões mais recentes foram definidas algumas variávies do kernel.ip.inet.br Reprodução integral ou parcial permitida desde que as fontes originais sejam mencionadas.forwarding=1 Ainda existem mais quatro opções relacioadas ao ipfirewall(4) que podem ser definidas no kernel.inet. Além do IPFIREWALL_DEFAULT_TO_ACCEPT nós ainda temos as seguintes opções: options options options IPFIREWALL_VERBOSE IPFIREWALL_FORWARD IPFIREWALL_VERBOSE_LIMIT=# A opção IPFIREWALL_VERBOSE permite logar o tráfego de pacotes com o ipfirewall(4). as informações sobre a atividade de pacotes daquela regra deixará de ser logada. porta) para outro.verbose=1 eksffa@eeviac~# sysctl -w net. Vamos tratar desse assunto com mais detalhes ao longo do documento. o syslogd(8) não será sobrecarregado com mensagens relativas à atividades do ipfirewall(4). por exemplo IPFIREWALL_VERBOSE_LIMIT=100 (padrão). porque não são necessárias para a implementação básica de um firewall. os comentários do kernel para essa opção diz que isso é uma forma de evitar negação de serviço com os logs gerados para algumas regras de firewall. http://www.fw.IPFW­HOWTO   forma estática no kernel. se definirmos. Redirecionar o pacote (FORWARD) é fazer com que ele siga de um ponto específico (host. que não restringem mais essas opções ao kernel estático.freebsdbrasil. . as seguintes opções no kernel terão efeito correspondente sobre as ações 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 opções do ipfirewall(4) sem recompilar o seu kernel. ecoando informações sobre atividade dos pacotes pro syslogd(4). A opção IPFIREWALL_VERBOSE_LIMIT=# define um limite de pacotes que serão logados para uma regra específica. quando existirem 100 ocorrências da mesma regra.verbose_limit=100 eksffa@eeviac~# sysctl -w net. Vamos aborda-la com mais detalhes posteriormente. mas não serão discutidas no momento. Essas opções envolvem situações mais complexas e específicas de roteamento de pacotes. O "#" deve ser substituído com o número de vezes que se deseje que as atividades de cada regra seja logada. por exemplo: eksffa@eeviac~# sysctl -w net. A opção IPFIREWALL_FORWARD permite que os pacotes sejam redirecionados para outros hosts.inet. mutáveis via sysctl(8). caso um possível ataque gere muitas ocorrências da mesma regra. utilizando o comando "fwd" do ipfirewall(4).ip. em cada regra que tiver a opção "log" definida.ip. Se você usa IPv6.com. você vai definir as variáveis correspondentes por meio do sysctl(8). Dessa forma. rede. Dessa forma. e vamos tratar delas assim que começarmos a tratar essas configurações.

Isso cria uma redundância de política de firewall aberta.0/8 A variável ${fwcmd} é definida anteriormente no rc.conf é altamente recomendável. a partir das configurações definidas no rc.com. sempre que a opção firewall_enable="YES" é adicionada no rc. você vai encontrar problemas na inicialização de alguns serviços. e a segunda regra evita que qualquer pacote externo adentre o endereço de host local (localhost address). onde o uso do /etc/rc.freebsdbrasil.0. e os seguintes comandos são 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. Se você fizer a opção por um script shell que carregue todas as suas regras e que seja executado sempre que o sistema iniciar.br Reprodução integral ou parcial permitida desde que as fontes originais sejam mencionadas.conf: firewall_enable="YES" firewall_type="UNKNOWN" Se você quer simplesmente habilitar o firewall para trabalhar algumas http://www. quando você define um firewall do tipo "OPEN" (aberto) no rc. Ainda que você defina ou não o tipo de firewall que você vai estar trabalhando. o /etc/rc.conf e o sistema é iniciado. Então. que é o endereço de loopback. A primeira regra é necessária pra permitir comunicação inter-processos locais (local IPC). é mais indicado definir o tipo de firewall como "UNKNOWN" (desconhecido) se você adicionou a política aberta (IPFIREWALL_DEFAULT_TO_ACCEPT) no kernel. protegendo assim o tráfego local.firewall.firewall e firewalls com política aberta (OPEN firewalls). especialmente serviços RPC(3).1. o rc.IPFW­HOWTO   2.firewall via rc.conf.firewall. A primeira regra em questão. já que a rede localhost é previamente bloqueada) e todo o tráfego interno seja aceito como saída. entre outros problemas. . O /etc/rc. você deve ficar atento a essas e outras regras que não devem faltar ao seu firewall. inclua as seguintes linhas no seu /etc/rc.conf. implicando quando o ipfw(8) vai ser executado de forma silenciosa (opção -q) ou não. posteriormente adicionando a regra número 65000. Se essas regras não existirem e o firewall tiver uma política padrão fechada. permite todo tráfego proveniente da interface de loopback (a lo0). Por isso vale ressaltar a impostância de se definir o firewall da forma correta. A mesma função do IPFIREWALL_DEFAULT_TO_ACCEPT no kernel.0).firewall ativa a seguinte regra no firewall: ${fwcmd} add 65000 pass all from any to any Essa regra permite que todo tráfego externo seja aceito como entrada (com excessão pro loopback. Para isso. e não quer permitir mais nenhuma regra do rc.firewall é lido e executado também. a regra número 65535 vai ser automaticamente carregada como "allow ip from any to any" no lugar de "deny ip from any to any". e a segunda regra bloqueia todo o tráfego direcionado à rede localhost (127. Se a política aberta é definida no kernel. Em seguida.0.

ou do responsável pelo firewall.firewall.com. Se a rede estiver por trás de uma implementação básica de NAT sem nenhuma opção de proxie carregada isso já seria impossível. 2. Essa regra vai evitar spoofing (técnica onde uma máquina se faz passar por outra.Essa definição de tipo de firewall (firewall_type) permite todo o tráfego proveniente da rede local (por exemplo. no caso você que está lendo esse documento. .2. ou ainda.Você pode customizar suas regras de firewall pra satisfazerem da melhor forma as suas necessidades. e a segunda é criar sua própria definição.Você vai ser obrigado a se familiarizar com o uso do ipfw(8) e sua sintaxe. e ficando mais a vontade com o ipfw(8). Existem duas opções distintas em relação à um comjunto de regras pro seu firewall: a primeira opção é usar uma das definições de firewall já existentes no rc. então é recomendado que você leia todas elas. ou seja. 2.br Reprodução integral ou parcial permitida desde que as fontes originais sejam mencionadas.firewall. ele é muito mais complexo que a definição CLIENT. então as opções "OPEN" ou "UNKNOWN" não são suficientes. antes de ativar qualquer um dos tipos pré-definidos. alterando seu endereçamento IP) não http://www. definida no kernel.freebsdbrasil. por duas rasões simples: . Contudo.IPFW­HOWTO   regras e ver como o ipfirewall(4) do FreeBSD funciona. com seu próprio conjunto de regras. Além de "OPEN" existem ainda mais 3 tipos de firewall disponíveis: "CLIENT" .2. não faz diferença se você colocou IPFIREWALL_DEFAULT_TO_ACCEPT ou IPFIREWALL_DEFAULT_TO_DENY como padrão. então você pode seguramente pular pro nosso capíulo 3.1. ou criar seu próprio conjunto de regras. Esse tipo de firewall funciona com política aberta ou fechada. pra se tornar familiar e saber exatamente como cada tipo de firewall funciona. Então não pule pra seção 3 (lol). O controle que gerencia qual definição de firewall carregar é feito pela opção firewall_type="" no rc. e requer que o usuário tenha algum conhecimento nos padrões RFC de Internet pra poder entender suas definições de regras de firewall. . Carregando Rulesets (conjunto de regras). permite que mensagens de email.firewall. Tipos de Firewall pré-definidos. Os autores do firewwall nativo do FreeBSD. se sua intenção é usar algum dos conjuntos de regras nativas já existentes no rc. É óbvio que a decisão final é a do administrador da rede. Apesar do nome SIMPLE. ipfirewall(4). apenas bloquear alguns hosts específicos.firewall. recomendam o segundo caso. que pode ser mantido como uma referência geral sempre que você precisar. se tornando mais experiente na definição de firewall. sem nunca tocar no rc.conf.Esse tipo de firewall é uma contradição. Se você preferir usar os conjuntos de regras de firewall pré-definidos no rc. "SIMPLE" . resoluções de nomes (DNS) e NTP sejam enviadas pra dentro e fora da rede. uma rede interna atrás de NAT) pra ela mesma. e manter as suas configurações propícias às suas próprias regras. Bloqueia pacotes fragmentados. e não permite nenhuma máquina que esteja fora da rede interna iniciar conexões TCP com máquinas dentro da rede.

3. Ou seja. Vai bloquear todos os pacotes endereçados como de redes privadas. não defina como padrão no rc.IPFW­HOWTO   permitindo a entrada de nenhum pacote que tenha um endereço de retorno igual ao endereço de qualquer host dentro da rede interna.org/internet-drafts/draft-manning-dsua-03. "CLOSED" . Na verdade.conf: firewall_quiet="YES" O formato do seu conjunto de regras será apresentado de forma um pouquinho diferente nesse arquivo. negando todo e qualquer tráfego da rede (exceto o tráfego via lo0 que nós vimos anteriormente que é controlado por padrão). a não ser que no seu kernel você tenha adicionado a regra de política aberta.rules. e vai permitir também pacotes fragmentados. basta incluir no rc. Essa definição simplesmente desabilita todos os serviços IP na rede.txt). de WWW.firewall. ao invés de um dos tipos de firewall abordados acima. ajustar o firewall pra CLOSED vai ser necessário em casos *extremos* onde você prefere (ainda que temporariamente) tirar toda a sua rede de funcionamento. Reprodução integral ou parcial permitida desde que as fontes originais sejam mencionadas. Esse tipo de firewall vai permitir tráfego de e-mail. Simplesmente as regras.ietf. A maneira de se estabelecer esse tipo personalizado de firewall é a mesma. e então vamos ver isso passo-a-passo.conf. aqui acontece tudo que nós insistimos que você deve evitar.conf. basta indicar o caminho (path) pro seu arquivo de regras: firewall_enable="YES" firewall_type="/etc/rc. de DNS.firewall. conforme definido no Internet-Drafts da IETF (disponível em http://www. Sintaxe de regras básicas do Ipfw(8).firewall. evitando o tráfego pra dentro ou fora da rede. em relação ao que você encontra no rc. conforme definido na RFC 1928. vamos construir um arquivo de regras próprio.firewall. A principal diferença é que você não vai usar nada correspondente à variável ${fwcmd} usada no rc. como na definição CLIENT. estabelece uma política fechada. então é recomendável que você especifique um arquivo.Tecnicamente essa definição não é um conjunto de regras de firewall. e vai bloquear ainda todas as redes nãoroteaveis.freebsdbrasil. http://www.2. ou seja. Se você decidiu estabelecer um conjunto de regras customizado.rules" Dessa forma você vai poder definir sua própria configuração de firewall no arquivo /etc/rc. porque não adiciona nenhuma regra. Então.br . 2. Posteriormente.com.firewall é um 'shell script' sh(1) escrito de forma que possa rodar por si próprio. o firewall não vai apenas bloquear. O motivo é simples. Se você preferir ainda que seu firewall seja iniciado de forma silenciosa. e NTP. enquanto o arquivo que define as suas regras personalizadas estão ali simplesmente para serem processadas pelo ipfw(8). o rc. o qual será carregado sempre que seu firewall for iniciado. contudo.2. utilizando a opção firewall_type no rc. e em relação às conexões TCP iniciadas por hosts fora da rede. vai também logar todas essas tentativas. Tipos de Firewall Personalizado.

Por exemplo: root@eeviac~# ipfw list 00101 deny log logamount 100 tcp from any to 192.168.br .com. 3.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.1. porque a ordem das regras também influi na forma como o ipfirewall(4) vai se comportar. seguindo a ordem do número da regra. e o número de bytes que esse tráfego gerou. a de número menor será mostra antes. nesse caso. com o comando ipfw(8).1. Qualquer regra pode ser adicionada pelo console. e o último pacote permitido pelo firewall foi há 9 segundos. você vai estar listando todas as regras ativas no momento. ainda que.168.1.freebsdbrasil. Antes de nos aprofundarmos nas sintaxes das regras do ipfirewall(4). se nós queremos listar o número de vezes que um pacote passou (ou foi bloqueado) por uma regra. a última vez que a regra 00101 bloqueou um pacote foi na madrugada do dia anterior.1.168. Listando Regras Ativas. podemos fazer o seguinte: root@eeviac~# ipfw -a list ou root@eeviac~# ipfw show Reprodução integral ou parcial permitida desde que as fontes originais sejam mencionadas.0/24 21 00103 allow tcp from any any 65535 deny all from any to any Dessa forma.1.168. Detalhe no comando date posterior que ilustra a data corrente.IPFW­HOWTO   A sintaxe das regras de firewall no FreeBSD são simples. http://www. a regra 00102 bloqueou um pacote também aos 33 minutos de 2 dias atrás.0/24 12345 00102 deny log logamount 100 tcp from any to 192. Pra mostrar a data e hora da última vez que um pacote coincidiu com uma regra basta usar a opção 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. contudo. Por último. vamos verificar como podemos listar as regras que estão ativas no momento. A forma mais simples possível de se listar as regras ativas no firewall: root@eeviac~# ipfw list Dessa forma. a regra número 00103 tenha sido adicionada antes da regra 00101.0/24 12345 00102 Tue Sep 18 00:33:12 2001 deny log logamount 100 tcp from any to 192.

etc. na seção 2. O padrão abordado é como deve ser quando estamos trabalhando com um arquivo de regras pra ser passado pro ipfw(8) via firewall_type="/caminho/pro/arquivo. que era o número da regra.firewall. grande parte das vezes.br Reprodução integral ou parcial permitida desde que as fontes originais sejam mencionadas. Isso é ótimo porque. "ipfw s" tem o mesmo efeito que "ipfw show". não vamos estar utilizando o programa de controle do firewall (o /sbin/ipfw). ou seja. a última regra vai sempre indicar a política do kernel. "allow" e "permit" são sinônimos pro ipfirewall(4). ou seja.IPFW­HOWTO   Os dois comandos vão apresentar as mesmas informações. Por enquanto não vamos abordar regras com as opções de stateful. Nessa regra. estaremos trabalhando com regras stateless. Por exemplo. em ordem como ela é verificada. add 1000 allow all from any to any Esse é o exemplo mais simples de uma regra. que é como ele foi usado no rc. Lembre-se que. a sintaxe mais simples pro ipfw(4) é: <comando> [<número da regra>] <ação> <protocolo> from <origem> to <destino> Os <comandos> mais importantes são "add" e "delete". sempre que um pacote combinar com uma regra. de forma geral. A segunda coluna informa quantas vezes aquela regra coincidiu com um pacote. A primeira coluna é o número da regra. Comandos básicos e suas funções. Bom.firewall" no rc. "ipfw l" o mesmo que "ipfw list". Mesmo se você tiver uma política de firewall aberta (OPEN) definida no seu /etc/rc. No ipfirewall(4). O <número da regra> varia de 0 até 65535. Por isso é extremamente importante estar atento a ordem (número) das regras. A partir de agora nós vamos. o ipfirewall(4) pára de examinar as outras regras pra aquele pacote. a primeira constatação do pacote evita que as outras sejam lidas.conf.freebsdbrasil. "all" (todos) os pacotes vindos de "any" (qualquer) lugar para "any" (qualquer) destino são permitidos ("allow").conf. gradualmente. acontece que "pass". dispostas da mesma maneira. eles tem o mesmo efeito.2. pelo console do FreeBSD.1 quando nós discutimos sobre tipos de firewall "OPEN" (aberto) nós trabalhamos com o parâmetro "pass". Sob circunstâncias especiais as outras regras podem ser procesadas. Uma simples tradução seria o suficiente pra explicar que "add" adiciona uma regra e "delete" a exclui. analisarmos cada opção e comandos disponíveis pra se construir um conjunto de regras de firewall. Existem algumas sintaxes curtas pra esses comandos. e indica a ordem que essas regras serão processadas no firewall. e finalmente a regra em sí. com uma única diferença. como a ordem de busca das regras para de processar ao encontrarem uma regra que combina com o http://www.com. contudo as variações permitem que o administrador fique o mais a vontade possível para escrever as suas regras quase que de forma literal. seguido do (terceira coluna) número de bytes que trafegaram pela regra. portanto a última regra sempre define a política padrão do firewall no kernel. . Então. a ordem como as regras são processadas no firewall do FreeBSD são do tipo "first match wins" onde. Nós já encontramos a mesma regra anteriormente. Durante os nossos exemplos. que deve preceder cada um dos nossos comandos. 3. caso estejamos configurando as regras de forma manual.

Vale notar que o uso do "reset" pode ser muito interessante pra enganar ferramentas que escaneiam as redes (network scanners).com. "reset" .Quando uma regra define essa ação. e o processamento das regras *pra esse pacote* termina. e responderia com um pacote RST para cada uma delas. Por outro lado. "<ação>" na sintaxe do ipfw(8) pode ser uma das seguintes: "allow" | "pass" | "permit" | “accept” .IPFW­HOWTO   pacote. sempre que um pacote combinar com essa regra. isso duplicaria o uso da sua banda de rede. o pacote é bloqueado. add 1100 deny all from any to any Essa regra nega todos os pacotes vindos de qualquer origem e indo pra qualquer destino. mesmo que a última regra (65535) negue todos os pacotes. para que apenas tais pacotes sejam processados por essa regra.50. ou seja. Uma solução simples é bloquear. mesmo que ele esteja por trás de um firewall de bloqueio. O processamento das regras do firewall continuam a buscar por outras regras que combinem com os pacotes. o protocolo especificado na regra deve ser "tcp". endereço esse obtido de forma dinâmica por monitoramento.230. add 1200 reset tcp from any to any Essa regra 'precária' (risos) bloquearia todas as conexões TCP vindas de qualquer destino. Motivos estatísticos óbvios. com uma regra prévia o endereço da máquina que está agindo dessa forma.1. e se a penúltima regra é a de número 65000.Quando um pacote encontra uma regra com essa ação. http://www. Como esse tipo de regra apenas se aplica pra pacotes TCP. O processamento das regras *pra esse pacote* termina.0/24 to 192. já que essa regra nunca vai ser processada.0/24 Reprodução integral ou parcial permitida desde que as fontes originais sejam mencionadas.freebsdbrasil. será permitido seu roteamento pelo firewall. e o ipfirewall(4) tenta enviar um sinal (flag) de TCP Reset (RST) pro endereço de origem do pacote.Qualquer pacote que combinar com uma regra cuja ação seja "deny" ou "drop" são silenciosamente bloqueados pelo firewall. add 1300 count all from any to any add 1310 count all from 200.Todos os pacotes que combinarem com uma regra cuja ação seja "count". indo para qualquer origem. determinará que o ipfirewall(4) incremente o contagem de pacotes. "count" . e não todos (proto "all") os protocolos de pacotes IP.br . "deny" | "drop" . já que normalmente podem detectar um serviço por trás de uma porta filtrada. definida pelo rc. a saída de "ipfw show" indicará mais uma ocorrência de pacotes nessa regra. então todo tráfego vai ser liberado. e o processamento das regras *pra esse pacote* termina. se alguém estiver praticando um ataque do tipo "network flood" em uma porta específica a qual o ipfirewall(4) está configurado para responder com pacotes RST.firewall pra permitir todo o tráfego da rede.168.

0.3. vindo de qualquer lugar e indo pra onde quer que seja. dando a impressão que a máquina se encontra fora da rede. dentre todos.0/24 e indo pra qualquer destino seja processado pelas regras a partir da regra de número 1800 "reject" . Quando um pacote combina com uma regra cuja ação seja "reject".br Reprodução integral ou parcial permitida desde que as fontes originais sejam mencionadas. Protocolo (proto) em "protocolo" na sintaxe básica de uso do ipfw(8). e a segunda regra nega toda conexão da máquina 10. fique a vontade: root@eeviacbsd~# cat /etc/protocols 3. ainda podem definir uma ou várias portas. um endereço de rede com máscara de rede (bitmask/netmask) e.0.0.IPFW­HOWTO   Essa (primeira) regra incrementa o número de vezes que um pacote passou pelo firewall. Sempre que um pacote coincidir com uma regra do http://www. add 1400 skipto 1800 all from 192. . estariam sendo enviados da rede 200.5 para qualquer outra estação.Essa ação é pouco utilizada atualmente. definido no /etc/hosts e resolvido por DNS.0. O endereço de destino e de origem de um pacote tem o mesmo formato em uma regra de firewall. basta atentar ao fato que a resolução de nomes via DNS pode mudar sem seu conhecimento prévio.168.freebsdbrasil. Essa é uma forma não silenciosa de negar o tráfego pelo firewall. Para uma lista completa das possibilidades.168.0/24 (origem) pra rede 192.4. Eles podem ser um nome. então o ipfirewall(4) bloqueia esse pacote e responde com uma mensagem ICMP do tipo "host unreachable". Os protocolos mais comuns são "icmp".1.50.158. add 1000 allow all from minhamaquina to outramaquina add 1100 deny all from 10. "skipto <número da regra>" .0/24 to any Essa regra faria com que todo o tráfego vindo da rede 192.1. "udp" e "tcp". essa ação também aumenta o uso da sua banda de rede. assim como a ação "reset".0/24 (destino). então. é o protocolo de comunicação que você quer que aquela regra combine.com.230. mas a relação de protocolos com os quais o ipfirewall(4) trabalha é enorme. Especificando endereços de Origem e de Destino.Todos os pacotes que combinem com uma regra cuja ação seja "skipto <número>" vão fazer com que o ipfirewall(4) continue processando esse pacote e buscando ocorrência nas regras que sejam de ordem maior ou igual ao <número da regra> indicado pela ação.5 to any A primeira regra permite todo o tráfego vindo da "minhamaquina" para a "outramaquina". no exemplo acima a regra 1310 não teria serventia alguma. Usar nomes ou endereços IP é indiferente. Definições de protocolos do tipo "ip" ou "all" são especificações gerais que englobam todos os protocolos.1. Já a segunda regra conta quantos pacotes. se o protocolo for tcp ou udp. Especificando Protocolos. Na verdade são todos os protocolos possíveis de uma rede. pode ser um endereço IP. 3. Uma observação aqui: se o processamento das regras fosse terminado quando um pacote encontra uma regra cuja ação seja "count". contudo.

de acordo com a ação definida pela regra. http://www.255 1 IPs Usáveis 1 Reprodução integral ou parcial permitida desde que as fontes originais sejam mencionadas. A máscara em bits também conhecida como bitmask especifica quantos bits do endereço de rede (192. É muito mais prático se nós trabalharmos com endereço IP em sua forma binária.3 3. então todos os endereços cuja origem seja a indicada nos dois primeiros octetos (ou nos 16 bits iniciais). mas frequentemente confundidos por pessoas que não tenham muito conhecimento em redes. A segunda regra tem uma função similar. Alguns breves exemplos de bitmask e netmask adicionais são ilustradas. ou seja. e o pacote é permitido ou negado. os primeiros 8 bits são 'bits altos'. No exemplo acima. Esse é um exemplo muito simples de um filtro baseado em estações.3: add 1000 deny all from not 192.168. Uma introdução à Netmask e Bitmask.0:255.0. os primeiros 16 bits dos 32 bits do endereço vão continuar os mesmos. a confusão que existe entre os conceitos binários e decimais costuma ser decisiva pra alguém sem muitos conhecimentos em rede.255.255) vão combinar com essa regra. para que o ipfirewall(4) bloqueie todos os pacotes que não seja da estação 192.0.0.0 até 10.168. serão permitidos por essa regra.168. contudo. De qualquer forma. e então serão bloqueados.168. utilizando as máscaras de rede. O primeiro octeto dessa regra é definido como 'bits altos'.0.0. A máscara de rede (netmask) indica quantos bits do endereço de rede deve ser monitorado pelo regra do firewall.0. ou “host-based filtering”. que filtra de acordo com o destino ou origem do pacote.0.0/16 to any add 2100 deny all from any to 10. Por exemplo. e ainda requer um pouco de noção de números binários. Bitmask Netmask 32 Total de Ips 255. toda a faixa de 10.255.0 A primeira regra permite todo o tráfego de pacotes vindo da rede cujo conjunto de endereços IP começa em 192. então todos os pacotes cujo endereço de destino seja 10 no primeiro octeto (ou seja.4. a seguinte tabela ilustra que faixa de endereçamento IP corresponde a qual bitmask e respectivo netmask em uma classe C de rede.freebsdbrasil. o processamento pra aquele pacote termina.255. Um firewall por filtragem de redes funciona de forma similar. O firewall do FreeBSD oferece ainda a possibilidade de inverter a expressão apresentada na regra com o comando “not”.0. O princípio básico que envolve máscaras de rede e bits de rede (netmask e bitmask) são simples. onde é necessário definir a máscara de subrede (netmask) ou ainda o bitmask.255.255.0.0. denotando algumas definições pra redes maiores. Vejamos: add 2000 allow all from 192.0) devem permanecer o mesmo pra cada pacote. nesse caso a rede 192.1.255.com. Como os primeiros 8 bits da rede é igual a 10. a segunda regra (número 2100) tem a máscara de rede 255.br . o que indica pro firewall que apenas os pacotes cujos primeiros 8 bits do endereço da rede devem ser filtrados. distinguindo-se apenas a notação de redes.0. Nesse caso.IPFW­HOWTO   firewall.168. para uma referência rápida.168.0.0 até 129.0. como indicado na ação da regra (deny).168.0. Como os primeiros 16 bits são os primeiros dois octetos do endereçamento da rede. A regra usa uma máscara (bitmask) pra indicar a abrangência do endereçamento da rede.

Então elevamos dois (possibilidades binárias) à quatro (bits): 2^4.255.248 255. portanto a faixa de endereçamento IP varia de 172. então sabemos que a subrede inicia nesse valor.255. de forma sucinta como usar a tabela acima.255.. e o número total de Ips disponíveis (que podem ser usados por estações) é sempre o total disponível na rede menos 2 (total – 2). já que um endereço completo de rede tem 32 bits. Sabemos agora que existem apenas 2 valores possíveis para cada bit.255.100. concluímos de forma lógica que temos apenas 4 bits ajustados como 'bits baixos'. 22 20 16 12 8.16.255.100.48.128.128. .255.255.0. Agora basta somar: 172.com.32.100.0 255.240 255.16.388608+e6 256^3 65534 (256^4)-2 Como você pode ver existe um padrão definido. Vamos descobrir então qual é a faixa de IPs que compõe uma subrede cujo endereço seja: 172.48.16.br Reprodução integral ou parcial permitida desde que as fontes originais sejam mencionadas.192 255. já que o endereçamento não decimal é binário.32.255. O último octeto da máscara de rede (netmask) começa com 255 e sempre se decrementa em valores múltiplos de 2.255.32 até 172. e 28 são altos (conforme indicado pela bitmask) subtraindo 28 de 32 restam-nos 4 bits (os bits baixos). Dessa forma poderíamos ter evitado todo esse cálculo matemático para encontrarmos o valor exato.100. nem sempre essa tabela vai estar disponível pra você consultar.0. Então percebemos que o bitmask do endereço é 28. vale lembrar que.16.254 255. Vamos ver.255.32 + 16 = 172.16.0.255. Mas. a menos que você a imprima e ande com ela na carteira.IPFW­HOWTO   31 30 29 28 27 26 25 24 . O número de endereço total de uma rede sempre sobra a partir da máscara que lhe foi atribuida. ou seja. que é o nosso caso. O motivo também é simples. Agora sim já temos o número de estações que aquele bitmask está indicando: 2^4 = 16.0 255.100. para cada rede/subrede existem dois endereços IP reservados para o endereço da rede e para o endereço de broadcast da rede.0.252 255. Aprenda uma vez e use http://www.0 0.0.0. ou seja.128 255.255.255.16.255. são endereços que não mudam.255..0 (todos IPs) 256^4 16320 32768 16318 32766 255.0 255. veríamos que 16 endereços IP corresponde a um bitmask de 28.100. Portanto.0 255.255.100.32/28 O primeiro detalhe ao qual atentamos é que o endereço da rede é 172. enquanto o bitmask se decrementa em múltiplos de 1.255.255.16.255.192. Isso quer dizer que todos os primeiros 28 bits do endereço são 'bits altos'. portanto é muito mais valioso aprender como o endereçamento funciona e aplicar os cálculos necessários. Se olharmos na tabela apresentada cima.freebsdbrasil.0 2 4 8 16 32 64 128 256 1 2 6 14 30 62 126 254 65536 8. o endereço de rede é 192.224 255.388606+e6 8 (256^3)-2 0 255.

5 também são permitidas pelo ipfirewall(4). Mas a declaração de máscaras para as portas indica que o firewall foi construído por alguém que domina completamente as definições de endereçamento de redes. pode-se usar um netmask pra definir a faixa de portas.0. 22 ou 23 na estação 172.5 allow tcp from any to 172.0. todos os pacotes UDP destinados pra faixa de portas de 1024 à 1028 na estação 172.br Reprodução integral ou parcial permitida desde que as fontes originais sejam mencionadas. . O uso de máscaras para definição de faixas de portas são raramente usadas. add add add add 1000 1100 1200 1300 allow tcp from any to 172. Como o valor de cada bit é binário.16.com.16. todos os pacotes TCP cujo destino é a porta 25 da estação 172.5 25 1021-1023 21. Na terceira regra.0. de 1024 até 1024+4 = 1024 até1028.5 são bloqueados. ou ainda. Sintaxe de regras avançadas do ipfw(8). mas são bem mais interessantes do que o uso de bitmask ou netmask pra endereços IP. podem ser separadas por vírgula. e como a máscara indica 8 bits. Isso possibilita que você permita ou negue acesso a um serviço em específico ao invés de controlar o tráfego das estações todas.23 1024:8 Na primeira regra. em casos mais elaborados.16.16. 4.5 deny udp from any to 192. Você pode também controlar o tráfego de conexões baseando-se em filtragem de portas.4. Na segunda regra todas as conexões TCP cujo destino seja qualquer porta da faixa 1021 até 1023 da estação 172. 3.IPFW­HOWTO   sempre. ele se mostra solenimente curto pra muitas situações mais complexas.0. É importante lembrar que você não pode definir “all” como protocolo na regra que especifica portas. e é estétitamente mais proveitoso. Mas a matemática também é bem simples. Embora o overview anterior sobre as criações de regras do ipfw(8) seja o bastante pra cobrir a maioria dos cenários e necessidades simples de um firewall. E. já que o número de bits de uma porta varia dependendo da porta em questão.16. ou então que se queira um maior controle sobre o direcionamento do http://www.2.16.5 allow tcp from any to 172. todos os pacotes TCP destinados às portas 21. então temos 4 portas que compõe a faixa de endereçamento da porta 1024. Especificando Portas e Faixas de Portas.16. e vírgulas quando se deseja definir várias portas em uma mesma regra. quando o sistema possui mais de uma interface de rede é possível que se queira definir ações especiais para algumas combinações de pacotes. tiramos 8 possibilidades de 10. A definição das portas em uma regra de firewall com ipfw(8) é feita após a declaração do endereço de origem ou do endereço de destino.0.168. Por isso o uso de hífen é recomendado pra se definir uma faixa de portas. restandonos apenas 2 bits. Como agora estamos tratando de Bitmask pra porta 1024.0.5 são permitidos pelo firewall.22.0. simplesmente definindo a porta após o endereço. A apresentação da faixa de portas na última regra é interessante. porque faz uso de uma netmask pra declarar a mesma. Uma faixa de portas pode ser especificada com um hífen. o valor pra ela é 10 bits. elevamos os bits disponíveis (2) aos valores possíveis (binário = 2): 2^2. finalmente na quarta regra. como por exemplo. ou seja.5 é permitida.0.freebsdbrasil. porque nem todos os protocolos trabalham com portas.

mas usar apenas essas opções pra definir de onde um pacote está vindo ou pra onde ele está indo via firewall não é muito confiável. Quando você quer filtrar pacotes que estão apenas entrando ou saindo pela rede. 4. e em que direção estão indo. As possibilidades de códigos pro 'ICMP unreach' pode ser indicada por número ou por nome. Primeiramente. 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. Essas regras podem identificar de onde esses pacotes estão vindo. as opções "in" e "out" podem ser utilizadas com precisão. poderíamos definir: add 1000 allow all from any to any in Pra filtrar pacotes indo através de uma interface em particular. e montaremos as regras aos poucos.2. a possibilidade de criar regras que verifiquem os pacotes de acordo com uma interface em especial (aplicável quando você tem um sistema com múltiplas interfaces de rede). A ação "unreach". http://www. Uma das mais importantes funcionalidades do ipfw(8). vamos introduzir uma nova "ação": "unreach <código>" . . mas nós vamos com calma.freebsdbrasil. Ambas opções ("in" e "out") correspondem ao campo "interface-spec" no modelo de sintaxe dado anteriormente. A Sintaxe pode parecer inicialmente confusa.br Reprodução integral ou parcial permitida desde que as fontes originais sejam mencionadas. Se você não sabe onde esses códigos são utilizados. serã respondido com um código 'ICMP unreach' (código ICMP de indisponibilidade). Então. Segue agora uma breve lista de 'ICMP unreach codes' (os códigos em questão) e seus nomes correspondentes. Dessa forma.com.IPFW­HOWTO   tráfego. que não foi comentada anteriormente na seção 3 desse documento é o controle de fluxo e de interface. e normalmente. vamos expandir o modelo de sintaxe que estávamos trabalhando no ipfw(8) para o seguinte: <comando> [<número da regra>] <ação> [log [logamount <número>]] <proto> from <origem> to <destino> [<interface-spec>] [<opções>] Todas as opções entre colchetes fazem menção à novas funcionalidades que iremos discutir nessa seção.Qualquer pacote que combine com uma regra cuja ação seja "unreach". Até agora o senso de direção que nós adotamos simplesmente definia os endereços de origem e de destino. não tem porque você tentar usa-los: net host protocol port needfrag srcfail net-unknown host-unknown 7 isolated 4. Nós vamos inclusive cobrir uma nova "ação" que não foi relatada anteriormente. antecedendo qualquer possível opção extra. quando decidirmos filtrar todos os pacotes vindos de qualquer lugar e indo pra qualquer lugar.1. são definidas próximas ao final de cada regra. ou seja. e posteriormente a leitra do conjunto de regras será terminada.

visto que elas permitem a filtragem de pacotes específicos vindo para o firewall. Dessa forma. e se deslocando através de uma interface especificada. quando entradas que estiverem usando "in" apresentarão a utilização do "via" dependendo da definição de um "in" você listar as regras de firewall.3. e quiser filtrar todos os pacotes vindos de qualquer lugar e indo pra qualquer lugar.br Reprodução integral ou parcial permitida desde que as fontes originais sejam mencionadas. e inverte a opção se uma '!' (exclamação) for devinida antes do <tipo>. essas opções oferecem muito mais controle sobre o tráfego da rede em um sistema de interfaces múltiplas. se estivermos usando uma placa de rede 3Com 3c59x PCI. essa definição pode confundir usuários não experientes. contudo isso não é preciso. ou seja. e. e qualquer outro sistema em geral. TCP e IP são apresentados em vários formatos distintos. Pacotes ICMP. saindo por ele. não mas apresentará a citação "recv" ou "xmit". cada um é definido por um número. se você tiver um sistemas com múltiplas interfaces. vindos especialmente dessa interface.3. Nós podemos filtrar cada um desses tipos usando uma das seguintes opções do ipfw(8). No geral. Combinando tipos de pacotes ICMP e TCP específicos. Os 15 tipos de pacotes ICMP são: 0 3 4 Echo Reply (Resposta de Echo) Destination Unreachable (Destino Indisponível) Source Quench (Origem extinta) http://www. Esses tipos de pacotes são definidos por várias _flags_ (opções de identificação). além do que. "icmptypes <tipo>" . você pode usar "recv" ou "xmit" no lugar de "via" quando você for criar alguma regra que faça uso de "in" e "out". 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. 4.Essa opção filtra o pacote ICMP do <tipo> definido. ou um "out" respectivamente. com origem e destinos quaisqueres.com.1. ao final de cada regra: 4. Você pode ainda especificar faixas de 'icmptypes' utilizando hífen ou separando-os por vírgula. o seguinte seria o suficiente: add 1100 allow all from any to any in via xl0 Ou talvez. pode fazer o seguinte: add 1200 allow all from any to any out via any Você vai notar que. .IPFW­HOWTO   podemos usar a opção literal "via". mas que esteja ao menos saindo via *alguma* interface. icmptypes (tipos icmp). Pra filtrarmos qualquer pacote. atualmente 15 tipos diferentes de pacotes ICMP que podem ser filtrados. sua interface será "xl0". Existe.freebsdbrasil. as ou "out" combinadas com "via". seguida do nome da interface. o ipfirewall(4) distingui se a interface está recebendo o transmitindo o dado. todos os pacotes que não forem desse tipo serão combinados.

Usar filtros de pacotes ICMP é muito útil. saiba simplesmente que o tipo 3 identifica qualquer um desses códigos. ou seja.Essa opção filtra qualquer pacote TCP cujo cabeçalho contenha alguma das flags (opções) identificadas. mas ninguém de fora pode pingar dentro. por exemplo. tcpflags. Naturalmente essas opções só podem ser definidas quando o protocolo da regra for "icmp". A segunda permite que todos os pacotes icmp do tipo 0 (resposta de echo) entrem pelo firewall. Veja as opções de 'flags': fin Request for connexion termination (pedido de finalização da conexão) syn Request for connexion initiation (pedido de inicialização da conexão) rst Reset Connexion (Redefinição da Conexão) psh Push Flag (opção Push) ack Acknowledgement (conhecimento. você pode permitir que qualquer cliente dentro da sua rede interna pingue qualquer estação pra fora da rede. 4. permite que qualquer cliente faça um pedido de echo pra fora. Em resumo. dessa forma filtrando todos os pacotes TCP que não possuam a <flag> em questão. especialmente pra controlar ping. e permite a entrada da resposta pra dentro do firewall. então. enquanto você bloqueia que qualquer estação externa pingue o seu gateway. todos. Uma definição inversa também pode ser utilizada se colocarmos uma '!' (exclamação) antes da <flag>. ou seja.com.br Reprodução integral ou parcial permitida desde que as fontes originais sejam mencionadas. especialmente o tipo 3. ou qualquer outro cliente interno. . concordância com a conexão) http://www.IPFW­HOWTO   5 8 9 10 11 12 13 14 15 16 17 18 Redirect (Redireção) Echo Request (Pedido de Echo) Router Advertisement (SPAM de roteamento? :-)) Router Solicitation (Pedido de Roteamento) Time-to-Live Exceeded (TTL Excedido) IP header bad (Cabeçalho IP malformado) Timestamp Request (Pedido de Timestamp) Timestamp Reply (Resposta de Timestamp) Information Request (Pedido de Informação) Information Reply (Resposta de Informação) Address Mask Request (Pedido de Máscara de Rede) Address Mask Reply (Resposta de Máscara de Rede) Se você ficou curioso pra saber como esses tipos ICMP. todomundo protegido pelo firewall pode pingar qualquer estação externa.freebsdbrasil. correspondem aos códigos de indisponibilidade que podem ser criados com a opção "unreach". e a regra seguinte bloqueia todos os pacotes icmp do tipo 8 de entrarem. "tcpflags <flag>" . setup & established. As três 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. e não permite que ninguém de fora faça um pedido de echo pra dentro do firewall.2.3.

e a maioria dos outros sistemas UNIX de verdade não são sucetíveis a esse tipo de ataque. Na grande maioria dos casos. se quizermos simplesmente negar todos os pacotes TCP que estiverem entrando no firewall com o cabeçalho SYN definido.3. é recomendável bloquear pacotes http://www. Essa opção se chama "setup". se você tem clientes Windows por trás do firewall.Finalmente podemos trabalhar com alguns pacotes IP específicos. 4. RR (para: Record Packet Route). e TS (para: Timestamp).freebsdbrasil. Dessa forma.4. ou seja. Se você não sabe pra que serve cada uma dessas flags.Qualquer regra contendo essa opção vai filtrar todos os pacotes TCP cujo cabeçalho indique a flag SYN ajustada. Essa é a base de implementações "stateful" de um firewall. visto que ela é enviada quando uma conexão TCP é iniciada. ipoptions. as opções "established" e "setup" foram disponibilizadas. .br Reprodução integral ou parcial permitida desde que as fontes originais sejam mencionadas. "setup" .Exatamente como existe uma opção especial que identifica um pedido de inicialização de conexão TCP ("setup"). os pacotes fragmentados devem ser bloqueados pelo firewall. Reconhecendo Pacotes Fragmentados. ja foi iniciada. Pela grande importância de facilitar o controle de conexões TCP. Vamos trabalhar com elas de forma mais detalhada depois. "ipoptions <flag>" . É claro que só podemos trabalhar com a opção "setup" quando o protocolo indicado é o "tcp". Utilizando estas opções (ou mesmo suas definições nativas correspondentes às "tcpflags") podemos ter inicialmente um controle de conexões TCP mais simples. dentro da sua rede. Mesmo considerando que o FreeBSD. existe inclusive uma opção separada do ipfw(8) dedicada especialmente pra definir pacotes TCP cujo cabeçalho tenha a flag SYN ajustada. temos duas opções: 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. 4. LSRR (para: Loose Source Route). então não haverá necessidade de construir regras que façam uso delas. Vale a pena ilustrarmos a necessidade do protocolo ser "tcp" quando trabalharmos essas regras.ou Negação de Serviço). dessa forma oferecendo facilidade na criação de regras.com. Receber um número grande de pacotes fragmentados pode indicar a eminência de um ataque do tipo DoS (Denial of Service . Pacotes fragmentados podem ser filtrados com a opção "frag" do ipfw(8). os sistemas Windows são frequentemente muito vulneráveis. "established" .IPFW­HOWTO   urg urgentes) Indicate Urgent OOB data (indica um OOB de dados A <flag> SYN é a mais interessante. A <flag> que define um tipo de pacote IP é nomeada SSRR (para: Strict Source Route).3. existe também uma opção que identifica quando uma conexão já está estabelecida. a mesma ação é tomada: todos os pacotes TCP SYN vindos de qualquer (any) origem para qualquer (any) destino serão negados. Dessa forma. Por ser tão importante.

Uma poderosa função que outros firewall (como o IPFilter) não possuem é a filtragem de pacotes baseada em GID/UID. e em contrapartida ter um grupo de usuários de shell que não precisam de muita banda. O Ipfirewall(4) tem a capacidade de filtrar pacotes de acordo com o UID ou GID do dono do processo o qual originou uma conexão. Ninguém mais será permitido pendurar Bots.10 pra estabelecer conexões TCP pra fora da rede. dessa forma. e nesse caso o filtro baseado em UID/GID também viria bem a acalhar.0.0. Se você quer se assegurar que um ou mais Hosts Virtuais não poderão ser usados por ninguém mais que o dono do IP virtual. A segunda: você também não pode utilizar o "frag" se estiver especificando portas TCP ou UDP. quando estivermos cobrindo o "traffic shaping" com ipfirewall(4). Por motivos de segurança. você bloqueia todos os pacotes fragmentados. O protocolo UDP também pode ser usado para filtragem de pacotes baseada em UID/GID. Outra utilização possível pra UID/GID seria habilitar limitação de uso de banda para cada usuário.0. Quando você for usar a opção "frag" pra filtrar (e bloquear) os pacotes fragmentados.10 to any out uid patrick add deny tcp from 172. Filtragem baeada em UID e GID. Por exemplo. você pode definir um grupo de usuários que tenham contas rápidas de FTP. você pode definir uma regra baseada em filtragem de UID. Clientes de IRC ou qualquer outra coisa que precise estabelecer conexão TCP (quase tudo) nesse endereço IP. A primeira é que você não pode usar "frag" quando também estiver usando a opção "tcpflags".168. todo o tráfego do host virtual que não seja do próprio usuário seja bloqueado: add allow tcp from any to 172.freebsdbrasil. você define qualquer pacote fragmentado. Dito isso. talvez seja necessário voce logar o tráfego de rede de um usuário em particular. não importando pra qual porta ou serviço eles estejam sendo enviados. tem duas regrinhas básicas que você deve seguir. o UID/GID do ipfw(8) sempre vem bem a acalhar. Por motivos lógicos só se pode filtrar pacotes que tenham sido gerados por processos locais. ao invés de limitar pra cada estação ou rede. definindo uma regra pro GID em questão. Uma pequena dica é sempre definir as regras baseadas em UID/GID antes das outras regras.168.10 to any Essas regras permitem que apenas o usuário 'patrick' vai poder utilizar a alias de IP (Apelido de IP. visto que o http://www.com. 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.16.5.0. contudo nenhum outro protocolo fora esses dois podem.br Reprodução integral ou parcial permitida desde que as fontes originais sejam mencionadas. ou não define nenhum. Na verdade sempre que se queira definir um comportamente distinto do firewall com base no usuário que acessa o serviço. IP-Alias ou IP vhost) 172.IPFW­HOWTO   fragmentados pra protege-los. para que. As opções a serem utilizadas são "gid" ou "uid" seguidos do GID/UID ou do nome do usuário/grupo que estivermos filtrando.10 in add allow tcp from 172. Um uso em potencial dessa função é restringir o número de IPs virtuais em um servidor de shell. . Vamos ilustrar outras limitações de bandas definidas por GID posteriormente.16.

Por isso a importância de se definir que tipos de regras serão logadas.2. se o conteúdo dos pacotes eram fragmentados (indicantivo de muitos ataques de negação de serviço – DoS). Isso garante desempenho e evita que se bloqueie ou permita um pacote antes de verificar qual usuário originou o tráfego. . e por incrível que pareça ainda é sinônimo de perigo pra administradores imprudentes. os logs de firewall são importantes pra rastrear crackers ou pessoas má intencionadas. 5. A possibilidade de verificar posteriormente quais conexões foram negadas. 5. 5. Configurações de Logs do sistema. o que a maioria dos novos administradores que experimentam quando eles habilitam o ipfirewall(4) pra logar.2. você tem que incluir ao menos as seguintes opções no kernel (não se esqueça de iniciar seu sistema com o novo kernel após a compilação do mesmo): options IPFIREWALL_VERBOSE Você ainda pode habilitar a seguinte opção: options IPFIREWALL_VERBOSE_LIMIT=# Nós já mencionamos essas opções anteriormente. Normalmente logar pacotes permitidos de serviços públicos (como WWW) não é uma boa indéia.freebsdbrasil. visto que o próprio serviço (servidor WWW) também mantém logs das atividades de acesso.com. Opções do Kernel. possibilita saber onde as conexões estão sendo feitas. Propriedades de Logs.estar logando regras que combinam com pacotes muito frequentes. enfim. e também utilizar muito espaço em disco pros arquivos de logs.br Reprodução integral ou parcial permitida desde que as fontes originais sejam mencionadas. As vantagens de manter os logs do firewall ativo são óbvias. . Mas logar também tem o seu lado negativo. Esse pequeno inconveniente é o resultado da combinação de: . Em especial. e a frequência de pacotes em um serviço como esse é muito grande. de que endereços elas vieram.1.não ter desabilitado logs pro console e pros terminais de root (péssima idéia). quando estavamos revendo http://www. Ataques de negação de serviço que tendem a sobrecarregar discos rígidos é um dos tipos mais antigos de atividade má intencionada. Pra habilitar os logs do ipfirewalll(4) no FreeBSD. 5. pra que rede ou estação elas estavam indo. Por outro lado. . Dependendo do tipo de dado que você está logando você pode se perder com a abundância de mensagens.IPFW­HOWTO   ipfirewall(4) termina a verificação da lista das regras quando um pacote combina com alguma das regras em uso. por quem e quando.não estar controlando limite de logs com o IPFIREWALL_VERBOSE_LIMIT.1. é o seu terminal abarrotado com mensagens sobre a atividade de pacotes. Logs (Logging). se você não for cuidadoso.

ao invés de simplesmente logar no arquivo padrão (/var/log/messages). Vamos assumir então que você quer que todos os logs relativos ao ipfirewall(4) sejam armazenados em /var/log/ipfw/ipfw.2. O limite definido pra IPFIREWALL_VERBOSE_LIMIT fica à critério do administrador. e todas as outras ocorrências seriam identificadas sob uma expressão genérica como por exemplo: Jan 29 03:26:55 meuservidor last message repeated 45 times Normalmente essas mensagens são logadas em /var/log/messages além de serem impressas no console do sistema também. Se você quiser modificar esse comportando do syslogd(8). isso pode ser feito também. http://www. Essa segunda opção do kernel limita o número de mensagens consecutivas enviados ao sistema de logs do FreeBSD. o syslogd(8).conf(5): !ipfw *.conf. e ainda. por questões óbvias de segurança. quando você aciona essa opção no kernel. Mas se você quer definir um arquivo separado pra logar tudo de forma distinta. o número de mensagens consecutivas relacionada a uma conexão em particular é limitada ao valor (número) específico. apenas 10 mensagens consecutivas a respeito de determinada conexão serão logadas no syslogd(8). 5.log.conf(5) pra enviar todas as mensagens relativas ao ipfirewall(4) pro arquivo /var/log/ipfw/ipfw.com.* /var/log/ipfw/ipfw.log. quando dada regra do firewall é ativada.IPFW­HOWTO   a ativação do firewall. se você julgar ter espaço em disco o bastante pra trabalhar com rotacionamento de logs (Log Rotation) você não precisa definir a opção de limite de verbosidade no Kernel. Você pode configurar o syslogd(8) pra logar as atividades do ipfirewall(4) em um arquivo separado. você terá que editar o /etc/syslog. 2) Configure o syslog.freebsdbrasil.log eksffa@eeviac~# Tenha certeza que o diretório e arquivo em questão não tenham permissões de leitura pra outros usuários senão o dono do arquivo. pra isso vai utilizar o comando touch(1): eksffa@eeviac~# mkdir /var/log/ipfw && touch /var/log/ipfw/ipfw. mas valores acima de 10 já proporciona um tráfego alto de mensagens em servidores muito requisitados. seguindo três passos relativamente simples: 1) Crie o seu novo arquivo de log para o ipfw(8) e.br .log Reprodução integral ou parcial permitida desde que as fontes originais sejam mencionadas. crie também o diretório de logs que você achar conveniente.log) sob tal diretório. A forma mais fácil de fazer isso é adicionar as seguintes linhas no final do syslog. O syslog. Portanto. Configurando o syslog(8). Considere o seguinte: options IPFIREWALL_VERBOSE_LIMIT=10 Com essa entrada definida no seu kernel.2. Dessa forma você vai ter que criar o diretório em questão (/var/log/ipfw) e em seguida o arquivo de log (ipfw. como alternativa.conf(5) oferece uma flexibilidade considerável em relação à configuração sobre as formas com que o syslogd(8) vai tratar as mensagens do sistema.

Os consoles virtuais e pseudo terminais se comportarão de forma distinta em relação à mensagens.debug.debug.err. é sempre bom manter o bom hábito seguro de usar o syslog.freebsdbrasil.conf.conf(5): Insira a linha com “!ipfw” e indique o caminho pra onde as informações referentes às atividades do Firewall devem ser logadas. é de bom costume fazê-lo.notice.err *. Indique os mesmos alertas pra um usuário que você usa com mais frequência. então.mail. http://www.auth.err. Por padrão as seguintes linhas definirão quando as mensagens forem enviadas pra outros terminais: *. como definido na linha: *. Note que o usuário em questão é o 'root'.IPFW­HOWTO   Atente pra usar <TAB> (tecla tab) nesse arquivo ao invés de espaços simplesmente.emerg root root root * As linhas *.com. caso você trabalhe também com outros UNIX.news. Portanto mesmo você podendo ignorar a mensagem de advertência no início do /etc/syslog. Você vai reparar que as mensagnes do tipo "last messages repeated # times" (ou seja: últimas mensagens repetidas # vezes) serão também logadas.kern.crit /dev/console Lembre-se que o console na verdade é apenas o ttyv0 (ALT+F1). Não altere as mensagens que serão enviadas ao usuário Root se ele estiver logado. A forma mais fácil é usando o comando: eksffa@eeviac~# killall -HUP syslogd eksffa@eeviac~# Reprodução integral ou parcial permitida desde que as fontes originais sejam mencionadas. informações de log para o root e pro terminal são extremamente importantes pra se manter atento a qualquer coisa errada que estiver acontecendo com o servidor. cuja maioria não aceita espaços no syslog. como por padrão você não deve logar como root a toa. além desse arquivo. Se por bom senso você costuma estar muito logado com outro usuário que não seja o root. Então vamos resumir o que deve ser feito quando você for configurar seus logs pelo arquivo de configuração syslog.alert *.conf(5) aponte as seguintes entras: *. *. Não se recomenda de forma alguma que essas linhas sejam comentadas.conf(5) da forma indicada por ele.notice E ainda.conf.br . pra qualquer outro cujo syslog. o console também irá receber todas essas mensagens.err *. 3) Envie um sinal de reinicialização pro processo do syslogd(8). também é considerável configurar o syslogd(8) pra alertar o seu usuário.notice irão logar mensagens do kernel e também as exibirão no terminal onde o usuário especificado estiver logado.notice. kern. Mesmo assumindo que usar “tabs” não é obrigatório no FreeBSD pro arquivo /etc/syslog.err e *.conf(5). o usuário root será sempre alertado.

O newsyslog. consequentemente você não tem que reiniciar nenhum processo. rotação de logs são definidas por dois critérios: tamanho ou data. ou. No nosso caso. optar por algum outro mecanismo de rotacionamento de logs. Ou o ideal.conf) do arquivo.conf(5). nós indicamos que queremos que o arquivo de log seja rotacionado às duas da manhã de todo domingo.IPFW­HOWTO   5.conf(5) vai cuidar do rotacionamento dos logs do ipfirewall(4). Configuração de Log nas Regras. isso é tarefa pra um capítumo sobre administração do sistema FreeBSD. é uma opção especial. Se você deseja manter seus logs por mais que 10 semanas basta alterar o valor 10 pra qualquer um que você queira. você deveria pensar seriamente em configurar o newsyslog. com tanto que você confie. Agora que o ipfirewall(4) está configurado pra logar todas suas atividades.com. não estamos usando essa opção. ela indica qual arquivo vai ser rotacionado. Pra se ter uma boa noção de todas as configurações possíveis do newsyslog.log 600 10 * $W0D2 Z Essa linha pode ser adicionada no final do arquivo newsyslog. De qualquer forma é bom decidir uma maneira de controlar o crescimento dos logs dentro do seu sistema. Lembre-se.2. Essa é uma poderosa ferramenta de logs.3. A primeira entrada é um tanto quanto óbvia. O seguinte é o tamanho do arquivo quando ele deve ser rotacionado. “Z”) que o arquivo deve ser comprimido com gzip(1) sempre que rotacionar. Você pode criar seu próprio script pra rotacionar logs ou usar de terceiros. Vejamos: "log" – É o parâmetro mais comum.conf(5) de forma a garantir que o newsyslog(8) vá rotacionar os logs do ipfirewall(4). Existem dois parâmetros básicos pra usarmos em conjunto com nossas regras pra definirmos que queremos logar *aquela* regra. não existe nada que o cron(8) e um script não possa fazer nesse caso. criar uma rotina que faça backup em uma máquina separada (um LogHost) a cada 10 semanas. o newsyslog. Uma vez que tudo esteja pronto pra utilizar as funções de logs do ipfirewall(4). A quintar parte é quando (tempo) nós devemos rotacionar o arquivo.conf(5) é ativado pelo cron(8) do FreeBSD.br Reprodução integral ou parcial permitida desde que as fontes originais sejam mencionadas. Toda vez que uma regra que for definida o “log” for acionada. A segunda indica os bits de permissões pros arquivos rotacionados. . mas não tem porque nós explicarmos ela aqui. 5. Uma vez configurado. pro nosso caso de Firewall específico a seguinte entrada deve ser o bastante: /var/log/ipfw/ipfw. então a ação definida (“action”) por aquela http://www.freebsdbrasil. Depois definimos (a última opção especial. não importando o tamanho do arquivo de log. e definimos que vamos manter um histórico arquivado de 10 semanas. como alternativa. ou então gravar seus Logs em CD ou qualquer outra mídia barata e de grande capacidade quando for necessário. Configuração do newsyslog(8) pra fazer Rotação (ou Rotacionamento) de Logs (log rotation). Como você já deve ter concluído.3. e finalmente a última opção. e por isso não precisa de um Daemon rodando. A terceira parte é o número de arquivo de logs que se deseja manter rotacionando até que o mais antigo seja apagado. vamos começar a definir quais regras nós queremos logar quando elas forem filtradas.conf(5) é recomendado que você leia a página de manual (man newsyslog.

em uma política clara de firewall do tipo “CLOSED” ou seja.4 no FreeBSD 3. A filtragem de pacotes do tipo 'Statefull' e 'Stateless' são dois termos frequentemente encontrados em discussões cujo assunto seja ipfilter(4) e http://www.16. uma regra de firewall sua.x e FreeBSD série 3 acina de 3. . Nas versões anteriores à 3. porque é uma das últimas. Introdução à filtragem 'Stateless' e 'Stateful' de pacotes. deve parecer com o seguinte: Oct 09 18:59:31 SuaMaquina /kernel: ipfw: 65000 Deny TCP 172.com. definir um número baixo pra uma determinada regra.168. visto que é uma das últimas regras a serem checadas. tudo que deve ser permitido já o foi nas regras anteriores que suponhamos existir.x o padrão do “logamount” era 10. o que. então imagine a frequência de informações que serão logadas sempre que cada pacote for permitido pelo seu firewall. por exemplo.x. Essa definição é possível no FreeBSD 4.0. Esse tipo de regra pode facilmente proporcionar problemas pro seu disco local .0.2. portanto nos interessa manter logs das conexões negadas.freebsdbrasil. dessa forma só deixando de logar o período que um possível ataque ocorrer.br Reprodução integral ou parcial permitida desde que as fontes originais sejam mencionadas. as informações geradas pra tal pacote Data & Hora Número da Regra Ação Endereços IP do Destino & Origem Portas de Origem & Destino Direção do Fluxo A Device onde o tráfego aconteceu.-) Por outro lado. e zerar a mesma uma vez ao dia. Por isso tome muito cuidado pra não defnir “log” pra uma regra que a terão pacotes frequentementes assimilados a ela. como por exemplo: add 0500 allow log all from any to any Essa é uma regra que permite todo o tráfego de todos os tipos de pacotes de todas as redes pra todas as redes. são: Sempre que uma regra é logada.1:62307 192.4. Preste muita atenção pra escolher quais regras você quer logar e quais você não quer. definir “log” pra uma regra geral de negação é uma pedida considerável: add 65000 deny log all from any to any Essa regra é mais considerável. e da muito mais controle ao administrador que pode. quando logada.1:23 in via xl0 6. FreeBSD 2. em relação à regra anterior (500) é muito mais seletiva.x. Por definição.Esse parâmetro em seguida ao “log” define o número máximo de vezes que uma regra vai ser logada.IPFW­HOWTO   regra será logada todas as vezes que um pacote coincidir a regra. "logamount <número>" . Esse parâmetro é análogo à entrada de limite de verbosidade no kernel. Além do que o número da regra é 6500.

Você deve ser capaz de filtrar os pacotes que se comportarem de forma indevida. exatamente pelo fato dele criar regras dinâmicas especiais que permitem uma conexão em sua totalidade. etc) . você deve: . No geral. dependendo apenas do quanto o administrador do sistema é bom. portanto podem se beneficiar dos dois tipos de firewall.IPFW­HOWTO   ipfirewall(4). o que fazia a capacidade do ipfirewall(4) de criar regras 'stateful' muito limitada." "setup. ou se ela está se comportando de forma indevida. contudo essas opções eram as únicas.filtrar pacotes de protocolos específicos (icmp. O segundo é que. Esse é o primeiro princípio básico das informações que um firewall 'Stateful' precisa conhecer. geram tráfego de pacotes especiais que indicam o início de uma conexão (SYN) e o fim da mesma (FIN).br . Isso permite ficarmos atento de forma mais inteligente às atividades da rede. e tem vantagens efetivas quando se pretende: . e não trata pacotes como individuais. enquanto o ipfilter era a opção 'stateful' disponível. http://www. O modo de filtragem 'Stateless' tende a tratar cada pacote roteado pelo firewall como pacotes individuais. Esse tipo de verificação primitiva de estado de conexão (tcpflags. não iniciada. Esse ponto também é essencial a um firewall do tipo 'Stateful'. em negociação. Por isso anteriormente à versão 4. que não tenham associação alguma com qualquer outro tráfego que também estiver passando pela dada interface do firewall.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. E normalmente administradores de FreeBSD já são muito bons por natureza. Esse tipo de filtragem é o mais comum e o mais fácil de implementar.0 o ipfirewall(4) foi habilitado a trabalhar com funcionalidades 'stateful' mais extensivas.ser capaz de determinar se uma conexão esta se comportando de forma esperada. Em compensação. Toda a comunicação através de qualquer protocolo usa números de sequência que indicam em que ordem os pacotes serão lidos em um socket(2). e elimina essas regras quando a conexão foi terminada. Um firewall do tipo 'Stateful' cria regras dinâmicas pras conexões que estiverem em andamento. Antes um pouquinho de história. ou seja os pacotes pertencem a uma dada conexão. e mais desenvolvimento a respeito disso está em andamento no ipfirewall(4). esse tipo de filtro trata o tráfego como sendo composto de determinadas conexões.x do FreeBSD o ipfirewall(4) era chamado de tipicamente 'stateless'. As unicas excessões foram as regras a respeito das opções "tcpflags. conexões orientadas à protocolos como TCP.freebsdbrasil. Reprodução integral ou parcial permitida desde que as fontes originais sejam mencionadas. udp. negada ou permitida. Vamos então usar uma combinação dessas regras pra um primeiro exemplo prático de regras 'stateful'.saber à que estado pertence uma conexão (iniciada. é muito fácil juntar regras de firewall do tipo 'stateful' e do tipo 'stateless' em um mesmo firewall. examinando se o comportamento dessa conexão está aceitável. A partir do FreeBSD 4. Quase todas as regras que nós apresentamos anteriormente eram 'stateless'. terminada. com procedimentos validos. etc) . Por outro lado um firewall do tipo 'stateful' são incapazes de filtrar cada pacote individualmente.com. igmp. etc) existe no ipfirewall(4) faz muito tempo.filtrar pacotes corrompidos (fragmentados) ." e "established" que permitiam que nós checassemos o estado de uma conexão TCP.

A maioria dos administradores mais atentos que costumam ler as regras de firewall pré definidas no /etc/rc. costumaram fazer largo uso das funções “setup” e “established”.25 setup 172.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. Mesmo essas regras podendo ser usadas exclusivamente pra controlar conexões TCP de forma 'stateful'.1. se são de inicialização de uma conexão ou de uma conexão já estabelecida. e em contra-partida permitem que todos os pacotes TCP saiam pelo firewall ou entrem pela porta 22. A regra número 1000 vai permitir todos os pacotes que sejam parte de uma conexão TCP já estabelecida.16. por isso a importância de deixa-los passar. se o pacote for do tipo TCP SYN. Nesse caso. email. Os pacotes subsequentes relacionados ao serviço SSH serão permitidos pela regra 1000.0. e depois da conexão estar estabelecidade permite que todo o tráfego funcione normalmente.br .0/27 Reprodução integral ou parcial permitida desde que as fontes originais sejam mencionadas.freebsdbrasil. vindos de qualquer fonte pra qualquer destino serão permitidos.firewall.16. Na regra número 2000. já que eles farão parte de uma conexão já estabelecida.com. Essa é a essência de um firewall do tipo 'stateful' utilizando “setup” e “stablished”: Deixa passar pedidos de inicialização de conexões de um serviço (porta) específico. Vamos dar uma olhada em um exemplo memos simples.IPFW­HOWTO   6. Nesse caso você vai perceber que as regras não ficam monitorando os pacotes TCP pra verificarem de que tipo eles são. a regra 1000 não será assumida. vamos estar usando as características mais básicas e conhecidas do ipfirewall(4) pra tratar filtragem 'stateful'. por outro lado algum pacote não fizer parte de uma conexão iniciada. http://www. o que demonstra certa limitação. e for destinado à porta 22 (serviço SSH).22. firewall_type no /etc/rc. todos os pacotes saindo pelo firewall. Pro nosso primeiro exemplo. pacotes TCP SYN iniciam uma conexão TCP. Você pode experimentar uma configuração parecida usando 'stateless': add 1000 allow tcp from any to any out add 2000 allow tcp from any to any 22 in Nesse exemplo.0.0/27 21.0/27 to any 53 any 53 to 172.16. e todos os pacotes entrando pela porta 22 também serão permitidos. sem verificar que pacotes são esses.16. que compõe a maiora das regras nesse arquivo. as duas regras anteriores vão permitir o roteamento dos pacotes desejados. e então a verificação das regras subsequentes vai cessar para aqueles pacotes. que envolve conexões ssh.0. vamos criar no nosso primeiro exemplo um conjunto simples de regras que filtram conexões ao serviço 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 política de firewall fechado (ou seja. Nesse caso. a regra vai permitir que ele seja roteado.conf não está definido como “OPEN” e não existe a entrada IPFIREWALL_DEFAULT_TO_ACCEPT no kernel do sistema). FTP e DNS pra rede 172. e então a verificação passa pra regra seguinte.0. Se. Configurações 'Stateful' Iniciais.

Consequentemente todas as conexões TCP estabelecidas serão permitidas na regra anterior. ou seja. 25 (FTP. mas também quando essa conexão é terminada. usando o que nós chamamos de regras dinâmicas. Lembre-se sempre que existe o fluxo em duas direços. o pedido de inicio de conexão (usando “setup”) é permitido pras portas 21. ou seja qualquer porta acima da 1024.0. Uma opção e um comando são utilizados pra controlar esse comportamente 'stateful' avançado: "keep-state" – Quando um pacote é combinado com uma regra que tenha essa opção ajustada. por mais simples que isso seja.com. Uma solução não muito prática é liberar as portas 21 e 22 de forma 'stateless' e forçar seus clientes FTP a estabelecerem conexões exclusivamente não-passivas (FTP Modo Passivo). de certa forma um conjunto de regras monitora não somente o início de uma conexão. Se você fosse fazer um firewall cujas regras fossem exclusivamente 'stateless'. 6. e permite pacotes UDP vindos da porta 53 de qualquer lugar entrarem pelo firewall.2. As regras 3000 e 3100 permitem pacotes UDP pra porta 53 de outros hosts. e essa prática pode ser adotada pra outros serviços que tenham comportamente similar a esse. http://www. Desde a versão 4. Configurações 'Stateful' Avançadas.br . O tempo que uma conexão TCP leva pra ser terminada pode ser controlada por inúmeras variávels do sysctl(8). UDP e ICMP de forma 'stateful'. você teria que manter todas as portas entre a 1024 e a 65000 abertas.freebsdbrasil.0. O problema é que nem todos os seus clientes (como os que usam Windows por exemplo) tem muita noção de FTP a ponto de coloca-lo em modo nãp-passivo. são regras dinâmicamente criadas pra conexões independentes. Cada regra dinâmica depois de um certo período de tempo sem serem utilizadas são descarregadas. permitimos a inicialização de uma conexão na porta 21 (onde todas as requisições FTP iniciam) e posteriormente permitimos o roteamento de pacotes pertencentes à essa conexão por qualquer porta (utilizando “stablished”). e ajusta suas ações de acordo a configuração utilizada. então uma regra dinâmica é iniciada. além de outros tipos de pacotes. os pacotes vindos de algum lugar e as suas respostas pra outro lugar. Essa é a forma mais eficiente de se controlar FTP via firewall. o ipfirewall(4) adotou características 'stateful' baseada em ótimos argumentos. como seu próprio nome sugeste. Como já foi dito. Nesse caso. A regra 1000 deve ser “from any to any” porque os pacotes TCP de conexões já estabelecidas devem ser permitidas vindo de qualquer origem pra qualquer destino.IPFW­HOWTO   Nesse exemplo. o protocolo FTP é um protocolo revoltadinho que estabelece suas conexões em qualquer porta não reservada. configurações de firewall 'stateful' usando apenas “setup” e “established” são muito limitadas. 22. portanto.x. O motivo é simples. Vamos analizar um caso especial: FTP. Regras dinâmicas é uma característica recente do ipfirewall(4) no FreeBSD 4. Essas duas últimas regras são 'stateless'.16. SSH e SMTP respectivamente) quando os pacotes são destinados à rede 172. essa filtragem é a mais simples existente. A porta 53 é a porta onde o serviço de nomes (DNS) roda. Reprodução integral ou parcial permitida desde que as fontes originais sejam mencionadas.0 do FreeBSD. Exatamente por permitir controle de conexões stateful apenas sobre o protocolo TCP. agora pode-se controlar conexões TCP.

A expressão “spoof” define um tipo de pacote que traz consigo informações de origem manipulada. e onde a conexão TCP legítima está sendo mantida.IPFW­HOWTO   "check-state" . Nas regras acina. uma delas é a verificação pelo firewall. Resumindo. nós já havíamos trabalhado com regras desse tipo utilizando as outras funções de 'stateful' e também utilizando 'stateless'. onde tínhamos regras destinadas à permitir apenas conexões SSH. não permitindo o roteamento do pacote. ai as regras dinâmicas serão verificadas no momento em que a opção “keep-state” for definida. essa regra presume que a política do seu firewall seja fechada. cada regra dinâmica é criada para uma conexão específica entre duas pontas (dois hosts) e suas respectivas portas. Se uma regra com esse comando combinar com um pacote. os critérios que definem a permissão ou não de um pacote passando por uma regra dinâmica são: Protocolo Endereço & Porta IP Destino & Porta IP Tempo da regra esgotado Como já foi dito. ainda que esse pacote fosse spoofado e não fosse um pacote legítimo dessa conexão TCP. Se não existir uma regra com esse comando em todo o conjunto de regras do seu firewall. a verificação das regras é terminada. É uma técnica não muito simples e que pode ser evitada de várias formas. a opção “stablished” permitia a ocorrência de qualquer pacote TCP vindo de uma conexão TCP previamente estabelecida. um pacote TCP spoofado poderia manipular seu endereço de destino e de origem. e dessa forma o pacote é negado pra regra final da política padrão fechada do firewall. a primeira regra faz com que o ipfirewall(4) verifique as regras dinâmicas. mas não manipularia a porta (a não ser com muita sorte) onde a conexão foi efetivada. Vamos então voltar ao nosso exemplo anterior. Todos os outros pacotes seriam bloqueados pela sua regra padrão de firewall fechado. que será sempre verificada na constatação da regra 1000. se o pacote for do tipo TCP SYN entrando pela porta 22 (SSH). e posteriormente a regra seguinte (2000) também falharia.com. Se o pacote não pertence a nenhuma conexão já estabelecida (ou seja. . Esse tempo de http://www. ou seja. mas dessa vez vamos usar regras mais avançadas de 'stateful': add 1000 check-state add 2000 allow tcp from any to any 22 in setup keep-state Só lembrando. Antes. não fazem parte de nenhuma regra dinâmica) então a verificação continua na regra 2000. podemos definir um período fixo de tempo até que a regra se esgote. Agora. essa nossa nova abordagem.br Reprodução integral ou parcial permitida desde que as fontes originais sejam mencionadas. Nessa nossa nova abordagem. Bom. aí a função “keep-state” ordena a criação de uma regra dinâmica. Dessa forma a regra 1000 (“check-state”) falha.freebsdbrasil. a regra dinâmica é descarregada depois de certo tempo sem ser utilizada.Esse comando define que a verificação das regras pelo firewall vai primeiro checar as regras dinâmicas. a não ser que o pacote fosse do tipo TCP SYN. do contrário a verificação continua. utilizando a opção “keep-state” e o comando “check-state” proporciona algumas vantagens sobre as outras configurações de firewall. ou seja o pacote não legítimo se faz passar por um pacote que na verdade não é ele. Dependendo de como uma regra dinâmica é utilizada. onde.

Esse pedido de inicialização de conexão se consiste de um pacote de sincronização TCP.inet. Posteriormente podemos modificar esses valores. Eis a listagem dos valores padrões dessas variáveis do sysctl: eksffa@eeviac~# sysctl -a | grep 'dyn.dyn_fin_lifetime: 20 net.fw.ip. Na regra seguinte.0.1:22.1:1234 e 192. onde ele não vai encontrar nenhuma regra referente à pacotes TCP vindos de 72. conforme indica as duas últimas variáveis do sysctl(8). e que essa regra tenha um tempo de vida de 20 segundos (que é o padrão pra pacotes TCP SYN).1:22 em resposta ao pacote TCP ACK enviado pro cliente. Vamos usar um exemplo pra demonstrar como isso funciona na prática: 1) – Uma conexão TCP legítima é iniciada da máquina 172.ip.15.1 que fica por trás do firewall.freebsdbrasil. Dessa forma a http://www.inet.16.com. .ip.1:22.dyn_short_lifetime: 5 eksffa@eeviac~# A primeira variável do sysctl(8) indica que o tempo de vida padrão pra cada regra dinâmica que use um pacote do tipo TCP ACK é 300 segundos. que vai verificar pelas regras dinâmicas e encontrar uma regra cujo tempo de vida não tenha terminado. A variável seguinte indica que o tempo de vida de uma regra dinâmica cujo pacote seja TCP SYN é 20 segundos. 4) – Depois de um segundo.0.0.dyn_syn_lifetime: 20 net. pra confirmar o pedido de uma conexão TCP. 2) – A regra 1000 do firewall faz com que o ipfirewall(4) verifique as regras dinâmicas.inet.ip.168. Dessa forma a regra dinâmica permite que o pacote trafegue com segurança pelo firewall.br Reprodução integral ou parcial permitida desde que as fontes originais sejam mencionadas.16. 3) – A regra 2000 é verificada e combinada.fw.fw.fw. em circunstâncias normais danificaria os recursos de rede de uma máquina Windows não preparada. então o “keep-state” ordena que se crie uma regra dinâmica pras conexões TCP entre as máquinas172. 7) – A regra 1000 verifica as regras dinâmicas e encontra o pacote spoofado com IP e portas de destino que pertencem a uma regra dinâmica existente.inet.0.*lifetime' net. contudo o IP e porta pra onde o pacote deve voltar não corresponde ao da regra (porque foi gerado de forma randômica pelo ataque). 6) – Um pacote TCP ACK spoofado. ICMP.dyn_rst_lifetime: 5 net.168.168.0.inet. que estivesse por trás do firewall.0.fw.0. 5) – Em seguida o pacote vai encontrar a regra 1000 do firewall de novo. etc).IPFW­HOWTO   duração pra cada tipo de regra dinâmica pode ser verificado utilizando as variáveis corretas do sysctl(8). um pacote TCP ACK é enviado pro servidor 192. vindo de um possível ataque que. um TCP SYN.dyn_ack_lifetime: 300 net. Depois 5 segundos de vida pras regras que encontrarem pacotes do tipo TCP RST ou outros pacotes (UDP.1 na porta 1234 pra porta 22 do servidor 192.168.1:1234 para 192. 20 segundos também de vida pra regras com pacotes TCP FIN.ip. ou seja. e que esteja permitindo o roteamento dos pacotes cujo IP e porta de origem sejam conhecidos. assim como IP e porta do destino.

ou seja. essa velocidade nem sempre é o bastante. Esses são exemplos e rasões primários. qualquer outro ataque com pacotes de qualquer tipo. então não define regra dinâmica praquele pacote.com. De qualquer forma. No nosso primeiro exemplo de regra 'stateful' esse pacote spoofado teria sido aceito. é a velocidade do ataque e velocidade com que esses pacotes podem chegar até o servidor (definido por quão larga seja a banda do atacante) e depois a velocidade e poder de processamento do servidor que está processando os pacotes que estão chegando pelo Stack TCP/IP. Felizmente. Dessa forma o tráfego de rede controlado pelo kernel fica saturado. Já a regra dinâmica criada exclusivamente para as duas pontas em comunicação. mas antes de explicarmos isso. não sobrando recursos o suficiente pra tratarmos todas as conexões legítimas que também estiverem chegando. Como podemos concluir na nossa ilustração prévia de um ataque TCP ACK Spoofado. e a filtragem pelo firewall continua pra regra seguinte. porque cada novo pacote com porta de IP randomicamente criada não encontraria uma regra dinâmica que o permitisse. porque a regra que continha “established” como dependência teria sido cumprida. . A ação mais comum desse tipo de ataque consiste em enviar inúmeros pacotes TCP SYN (SYN FLOODs) pra uma determinada estação na rede. Linux. Mesmo considerando que o Stack TCP/IP do FreeBSD é desenvolvido de forma à eliminar randomicamente conexões TCP que estiverem em fila de espera de forma inativa. contudo poderosos em relação à vantagens das operações avançadas de 'stateful' do ipfirewall(4). pois aceitava todo pacote com um destino em particular. eles vão fazer pedidos falsos de conexões de forma mais rápida do que eles podem ser eliminados da fila. Pacotes TCP SYN spoofados são usados com muita frequência em taques de rede.br Reprodução integral ou parcial permitida desde que as fontes originais sejam mencionadas. vamos dar uma olhada em um tipo de ataque popular utilizando TCP SYN. 9) – Consequentemente o pacote é bloqueado pela regra padrão do firewall que é do tipo fechado. nós estamos trabalhando com FreeBSD. esse tipo de ataque pode ser devastador dependendo da política de eliminação das filas adotado no sistema (via sysctl(8)) e dependendo também da largura de banda da rede. que tivesse ao menos a 'flag' ACK definida. ataque esse conhecido como SYN FLOODs.IPFW­HOWTO   regra 1000 falha. SYN ou ACK também seriam evitados pelo Firewall. não existe uma forma lógica de se manipular. evitando o roteamento de novas conexões legítimas. de modo que toda a conexão fique em estado de espera. relacionado à esse tipo de ataque. por estarem esperando suas respostas em fila. verificou pela porta de origem e consequente resposta da conexão. e o pacote Spoofado cumpriria esse critério. e o Stack TCP/IP do FreeBSD é mais poderoso do que o de qualquer outro sistema. dependendo do número de atacantes ao mesmo tempo. sejam até mesmo Unix. e da largura da banda dos mesmos. Os primeiros pontos em questão. No exemplo anterior poderíamos ter assumido um ataque diferente se o pacote spoofado fosse do tipo TCP SYN. Vamos assumir que. se os pacotes TCP SYN chegarem ao servidor de forma muito rápida. Esse tipo de vantagem o IPFilter também possui. ou alguns outros BSD Unix. 8) – A regra seguinte (2000) verifica que o pacote não é do tipo TCP SYN.freebsdbrasil. informação que é gerada aleatóriamente. Mesmo tendo http://www. Mas de qualquer forma devemos ficar muito atentos em relação ao número de regras dinâmicas que poderíamos abrir por pacotes TCP SYN spoodados.

Se a resposta do ping demorar mais que 5 segundos pra chegar a regra vai ser descarregada e o pacote não vai poder ser roteado.inet. utilizando sysctl(8). não é pra menos. então de uma olhada nas regras que nós usamos pra permitir que nossos clientes internos pudessem pingar qualquer máquina pra fora da rede. contudo você se lembra que nós comentamos que o ipfirewall(4) poderia manipular também filtragem 'stateful' de outro protocolos. como foi mostrado anteriormente. conexões TCP representam a grande maioria do tráfego gerado em rede. então você.dyn_short_lifetime do sysctl(8).0/27 está por trás do firewall: add 1000 check-state add 2000 allow tcp from 192. De qualquer forma a maioria dos atrasos de rede levam menos de 1 segundo. como administrador da rede deve elevar o valor da variável no sysctl(8). É claro.IPFW­HOWTO   certeza que o Stack TCP/IP do FreeBSD não seria sobrecarregado por tantas tentativas de conexões.-) Reprodução integral ou parcial permitida desde que as fontes originais sejam mencionadas. a criação das regras dinâmicas do ipfirewall(4) poderiam ser saturadas. a não ser que seja IRC . A melhor forma de evitar isso é diminuindo o tempo de vida das regras dinâmicas iniciadas por pacotes TCP SYN. Se você considera que as respostas de ping levarão mais que 5 segundos pra acontecer.ip. você pode verificar quantas regras dinâmicas existem criadas no exato momento. O protocolo ICMP usa a variável net.0. a regra padrão nega essa ação. através de uma outra variável do sysctl(8): net. ou seja. os pedidos que entrarem serão automaticamente negados.ip. quando estudamos a seção referente ao “icmptypes”.fw.com. e se alguém de fora tenta pingar uma máquina interna. Até agora nós trabalhamos essencialmente com regras 'stateful' que manipulavam conexões TCP. aumentar o número máximo de regras dinâmicas.ip.dyn_max: 1000 (default) Como o seu firewall 'stateful' em plena atividade. e ainda.0/27 to any out setup \ keep-state Dessa forma só os pacotes TCP SYN que saírem pelo seu firewall poderão ser roteados.168. Bom. http://www. assumindo que a rede 192.inet.dyn_count A melhor forma de evitar que pacotes spoofados utilizem todas as suas regras dinâmicas é evitar que qualquer máquina fora da sua rede inicie uma conexão TCP. 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.fw.inet.0. verificando a variável do sysctl(8): net. Esse é o mesmo tipo de proteção que o NAT e proxies transparentes de forma geral oferecem pras máquinas internas. Quando a resposta chega ela é permitida pela regra dinâmica que estabeleceu a conexão entre as duas pontas. que cria uma regra dinâmica pra cada pedido de echo que nossas estações internas façam pra fora. Isso pode ser feito facilmente com as seguintes regras.br .freebsdbrasil. de forma a colocar pacotes em espera.fw.168. enquanto ninguém poderia nos pingar.

245 80 Nós já conhecemos as regras estáticas apresentadas.freebsdbrasil. essa é a primeira vez que nós estamos encontrando uma regra dinâmica listada pelo nosso firewall.3. a regra número 2000. as regras também podem ser substituídas por novas regras dinâmicamente ativadas. Os tipos de regras correspondem ao fluxo do roteamento de pacotes através daquela regra. conforme aprendemos anteriormente. elas serão continuamente substituídas por novas regras. caso existisse mais de uma rede por trás do firewall. indicado pelo símbolo “<->” entre a Porta/IP de origem e de destino. e apenas uma delas poderiam pingar máquinas externas. #). O 'ty 0' indica o tipo de regra dinâmica em questão. Entre parênteses encontramos o valor “T” que indica o “timeout” (o tempo de vida) daquela regra.br Reprodução integral ou parcial permitida desde que as fontes originais sejam mencionadas. ou se a regra é bidirecional.71. Vamos examina-la com mais atenção: A primeira citação de uma regra dinâmica é o número da regra estática que a gerou. 6. ou seja o número de vezes que um pacote saiu pelo firewall através daquela regra. Na verdade escolhemos a regra assim porque é a forma que mais se aproxima do nosso exemplo inicial de controle do ping. do destino pra origem. contudo a regra inativa vai ter um valor de tempo de vida (“T”) igual a zero (T 0. Nesse caso ainda existem 54 segundos de vida para essa regra. 192. seguido do número total de bytes que os pacotes que passaram por aquela regra rotearam. contudo. ou seja. no nosso caso. . Anatomia de uma Regra Dinâmica. Vamos dar uma olhada na saída que você devei encontrar quando listar as regras dinâmicas de um firewall 'stateful' no seu FreeBSD: 00100 allow ip from any to any via lo0 00200 deny ip from any to 127. http://www.IPFW­HOWTO   A regra 2000 ainda poderia ter definido uma faixa de rede com permissão pra fazer o ping. No nosso caso temos apenas um tipo indicado. nesse caso essa é a nossa regra número 0. Uma vez descarregadas. Mesmos depois que uma regra dinâmica foi descarregada.1 2007 <-> 204. A não ser que todas as regras dinâmicas continuem em pleno uso. especialmente se o número de regras dinâmicas alcançou o máximo permitido pelas variáveis do sysctl(8). a regra não vai mais aceitar pacotes. em segundos. Depois do tipo da regra dinâmica podemos constatar o protocolo que a regra ta usando. A segunda parte é o número de vezes que aquela regra foi utilizada. simplesmente porque ela não existe mais.0. # 0) ty 0 tcp. Uma vez descarregada.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. Podemos verificar essa afirmação visualmente.168. A cerquilha (#) indica o número da regra.0. ou o número de incidências da regra. o símbolo de fluxo dos pacotes (no caso “<->”) e finalmente o IP/porta do destino da conexão.0.com. até que a mesma regra seja reiniciada. se ela permite apenas tráfego da origem pro destino. ou ressucitada pela mesma entrada “keep-state” da regra que a originou inicialmente. que tem a opção “keep-state” ajustada. você ainda pode lista-la com o comando “ipfw list”. seguidos do IP/porta de origem.200. que é o padrão: bidirecional.

contudo nem sempre você quer analisar as regras dinâmicas. já que são essas que criam as dinâmicas. 200. 200.210. entre as quais as mais importantes são: limitação de banda.42.70. entre outros. Note que existe conexões cujo tempo de vida já se esgotou. Ele permite que você controle a intensidade. Até agora a gente entendia como controlar roteamento. criação de filas de fluxo. devido ao enorme número de regras dinâmicas criadas. e ainda assim a mesma foi listada. uma solução é utilizar um paginador: eksffa@eeviac~# ipfw list | less OU eksffa@eeviac~# ipfw list | more 7.151 1180 <-> 200.70.151 1174 <-> 200. mesmo que já descarregadas pra oferecer controle total do firewall ao administrador. você vai perceber o quanto a saída de um comando pra listar as regras do ipfw(8) vão se tornar perturbadoras.45 21 02000 15 1372 (T 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. A inclusão do dummynet(4) no FreeBSD possibilitou um controle de tráfego extensivo. Controle de Tráfego (Traffic Shaping) se refere à possibilidade de controlar todo o roteamento de pacotes pelo seu firewall de diversas maneiras.IPFW­HOWTO   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. atrasos no roteamento (delays). cabe a você entender o que está acontecendo com o firewall.151 1176 <-> 200.42.70. agora controlar tráfego passa a significar mais do que simplesmente filtrar quem e quando pode acessar determinado serviço. direção e disponibilidade do tráfego. # 48) ty 0 tcp. # 55) ty 0 tcp. e apenas as estáticas.45 22 02000 31 1828 (T 217.freebsdbrasil.42. http://www. funcionalida essa que o IPFilter também não pode oferecer. rede e/ou estações. Nesse caso uma solução óbvia do mundo Unix seria: eksffa@eeviac~# ipfw list | grep -v '[<->#]' Ou se você quer analisar com cuidado todas as regras.210. Traffic Shape (controle de tráfego).45 22 Não vamos comentar a listagem acima. O ipfw(8) lista todas as regras dinâmicas. 200.com. quando você começar usar regras 'stateful' em grande escala.210. Bom.br .0. sejam estáticas dou dinâmicas. Reprodução integral ou parcial permitida desde que as fontes originais sejam mencionadas. a escolha e definição de políticas de permissões ou restrições de acesso.210.210.210. # 58) ty 0 tcp.

o qual corresponde à probabilidade estatística dos pacotes que serão liberados pelo firewall. Existem apenas duas restrições: probabilidade de ocorrências e a utilização de regras dinâmicas. Dummynet. 7. se nós quisermos restringir 20% dos pedidos de echo (echo requests) do ICMP. simplesmente porque é inviável.8 allow icmp from any to any in icmptypes 8 Podemos também querer negar 50% dos pacotes TCP SYN pro servidor web.9”) vai permitir o tráfego de 90% dos pacotes que passaram por aquela regra. O ipfirewall(4) possui uma ferramenta incrivelmente funcional pra auditar e testar uma rede. regra>] [prob <prob_ocorrencia>] <acão> [log [logamount <número>]] <proto> from <origem> to <destino> [<interface-spec>] [<opcoes>] Por exemplo. Um túnel nada mais é do que uma regra de Traffic Shapping que controla o roteamento. atrasos e filas de fluxo em cada regra à ser criada de forma não estática. Probabilidade de Ocorrências (Probability Matching). opção essa. em relação à performance. da mesma forma que uma “prob 0. A criação desses túneis é feita com o comando “pipe” do ipfw(8).2. uma probabilidade 0. 7. Segue então uma pequena extensão da sintaxe do ipfw(8) que nós estávamos acostumados: <comando> [<no. Essa ferramenta estatística faz uso da opção “prob” nas regras do firewall.com.2.8 do FreeBSD. Pra isso precisamos adicionar uma opção ao nosso Kernel: options DUMMYNET Depois de compilado o nosso kernel com mais essa opção (além das opções típicas do ipfirewall(4)). que foi incorporado na versão 2. seguida de um número entre 0 e 1.9 (indicada pelo comando “prob 0. Essa ferramenta permite que o administrador simule a restrição de pacotes de forma aleatória sob várias taxas de probabilidade.5 allow tcp from any to any in setup via ep0 A utilização de probabilidade de ocorrências é uma função nativa do ipfirewall(4).freebsdbrasil.IPFW­HOWTO   Todo gerenciamento mais rudimentar de uma rede. Dessa forma. Todas as outras funcionalidades pra se implementar Traffic Shapping requer o uso do dummynet(4). O tráfego é redirecionado à esses tuneis por meio do comando “pipe http://www. poderíamos usar a seguinte regra: add 1000 prob 0. a verificação da capacidade de banda. Faríamos da seguinte forma: add 1000 prob 0. dessa forma simulando um tráfego pesado na interface ep0. em relação à sua infra estrutura básica de tráfego e roteamento pode ser implementado utilizando-se ipfirewall(4) e dummynet(4). Nenhuma regra de 'Traffic Shapping' pode ser criada de forma dinânica. o administrador do sistema vai poder especificar a criação de túneis (chamados “pipes”) pra controle do tráfego.1. .br Reprodução integral ou parcial permitida desde que as fontes originais sejam mencionadas. canalizando as informações que posteriormente irão trafegar por endereços específicos de rede.1” permitirá apenas 10% de probabilidade.

Pra se obter o valor da MTU em uma interface de rede é necessário o uso do ifconfig(8): eksffa@eeviac~# ifconfig xl0 xl0: flags=8843<UP. Vamos então criar um túnel simples: pipe 10 config bw 100Kbit/s Note que.2 "plr" significa "packet loss rate" (taxa de perca de pacotes).BROADCAST.168.1 netmask 0xffffffe0 broadcast 192.168. a necessidade seguinte é definir o tamanho das filas dos túneis gerados. oposto da opção “prob” do ipfw(8). e co-existem porque a primeira é nativa do ipfirewall(4) enquanto a segunda faz parte do dummynet(4). A MTU de uma 'device' de rede define o tamanho máximo que um pacote vai ter naquela interface.br Reprodução integral ou parcial permitida desde que as fontes originais sejam mencionadas. 7. exatamente como “add” ou “delete”.. MTU = Maximum Transmission Unit.SIMPLEX.0. aconselhamos que o administrador assuma uma escolha pessoal entre as duas possibilidades. Mbyte/s. ou Unidade Máxima de Transmissão. simulando o que se conhece como “lag” do sistema: pipe 10 config delay 100 O valor que segue a opção “delay” é o tempo de atraso que nós desejamos.freebsdbrasil.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. que indica a taxa dos pacotes que serão roteados. definido em milisegundos. especialmente se a MTU da interface de rede em questão é relativamente grande. assim como nas regras de firewall. portanto o valor indica à que taxa os pacotes não serão roteados. . o “pipe” é apenas mais uma ação pro ipfw(8). Pra evitar qualquer confusão com a utilização de “prob” ou ®plr”. Kbyte/s. Esse túnel simples que criamos logo acima vai informações pra uma velocidade máxima de 100 Kilobits várias maneiras distintas de indicarmos as medidas de bit/s..RUNNING. Ambas são igualmente efetivas. Existem velocidade de tráfego: túnel de limitação de Uma outra maneira de controlar tráfego é usar a opção “delay” que força um atraso na comunicação. portanto antes de cada comando é feita uma chamada ao ipfw(8) (/sbin/ipfw pipe 10.0.com. Mbit/s. Existe ainda a possibilidade de proporcionarmos uma taxa de perca de pacotes.1.MULTICAST> mtu 1500 inet 192. limitar o fluxo de por segundo. por exemplo). Kbit/s. pra conseguirmos uma taxa de 20% de pacotes perdidos (equivalente a “prob 0. Por exemplo. Bom. Filas de Túneis (Pipe Queues). Nesse exemplo todo o tráfego roteado através desse túnel terá um atraso de 100ms.2. Byte/s.IPFW­HOWTO   <pipe #>” no ipfw(8). função essa igual à “prob” que comentalos logo acima. Cada banda deve usar a opção “bw” (de bandwidth – banda).8”) podemos criar o seguinte túnel: pipe 10 config plr 0.

uma configuração rasoável pra fila seria: pipe 10 config bw 56Kbit/s queue 5Kbytes 7. Pra evitar esse tipo de problema é recomendável ajustar manualmente o tamanho das filas (queue).br Reprodução integral ou parcial permitida desde que as fontes originais sejam mencionadas. mas não vamos definir uma MTU menor pra device. que seria nossa melhor opção. Cada 'slot' corresponde a um pacote. vai definir individualmente a banda. levaria aproximadamente 10. utilizando o ifconfig(8). que pode ser muito pra determinadas interfaces de rede com MTU grande e pouca banda disponível. Por exemplo. já que esse valor equivale à variável de multiplicação no tamanho da queue (fila). Máscaras de Túneis (Pipe Masks). isso gera gargalo e consequente atrasos na rede. Mas agora considere que você pode definir máscaras pra identificar um subconjunto de estações que pertencem ao mesmo túnel. . portanto 15Kbytes.. É importante entender a definição de tamanho das filas (queue) porque o padrão pra cada fila é 50 'slots'. a requisição pelas interfaces é maior do que o tráfego possível na rede. exatamente como netmasks e bitmasks identificam subconjuntos de http://www. e você quer limitar a banda pra 100Kbits/s pra cada máquina. Elas podem ser configuradas especificando-se o seu temanho em “Kbytes” ou por “slots”. ou seja. A fila pros pacotes então seria 1500 bytes (12000 bits) x 50. Esse é um atraso inaceitável pra por o tráfego em andamento. O padrão 50 'slots' foi definido por ser o tamanho médio de uma fila nas devices de rede. ou seja definir que uma fila tem 10 'slots' significa que aquela fila vai suportar apenas 10 pacotes simultâneos. equivale a multiplicação do mesmo pelo número de pacotes na fila. com o ipfw(8). a mais óbvia e primeira conclusão que um administrador tomaria seria criar túneis e regras individuais pra cada máquina. Existem duas formas de se fazer isso. Por padrão esse valor é comum entre as placas de rede. Façamos o seguinte então: vamos criar um túnel em uma rede que simule a velocidade máxima de um modem de 56K: pipe 10 config bw 56Kbit/s . A segunda opção é a melhor. nem vamos diminuir o tamanho da fila (queue). menor deve ser a fila.com. ou seja se você criar uma fila (queue) com 10 'slots'. Lembre-se.freebsdbrasil. No nosso exemplo acima. porque além de ser um valor mais compreensível. a MTU da placa de rede é 1500 (bytes). As filas são utilizadas pelos túneis pra forçar as limitações e atrasos de banda.IPFW­HOWTO   eksffa@eeviac~# Verificamos portanto que na interface xl0 em questão. por ser definido pela MTU da interface.. com o ifconfig(8). imagine que você tenha várias máquinas atrás do seu firewall. ou seja. O tamanho máximo de cada pacote. 600Kbits de fila. o uso de 'slots' requer que o administrador também defina o valor pra MTU da interface. contudo quando se tem uma banda pequena. em 'slots' que é mais fácil pra uma comparação com o padrão (que sabemos ser 50) ou em ®Kbits” que é uma melhor atribuição à quantidade de dados.2.2.7 segundos pra uma fila de 600Kbit ser preenchida. não vai agregar um valor somatório à banda pra todas as máquinas. Uma poderosa característica dos túneis é permitir múltiplas filas por fluxo. Normalmente esse valor é o ideal. Pra um túnel que esta limitando a banda à 56Kbit por segundo. quanto menor a banda disponível. o tamanho dela será 10 x 1500 bytes.

etc) como importantes e válidos. . Assumimos que apenas a definição dos túneis sem o direcionamento com ipfw(8) não faz mais sentido.0/16 to any in via <device> No primeiro instante as definições acima parecem confusas.168. especialmente porque essa também é a primeira vez que nós incluimos as regras do ipfw(8) pra direcionar os pacotes pros túneis.br Reprodução integral ou parcial permitida desde que as fontes originais sejam mencionadas. sempre (nas duas regras) o tráfego ocorreria pela interface <device>. e a regra 2000 definiu que todo o tráfego entre a nossa rede interna entraria pelo túnel 20. A regra 1000 definiu que todo o tráfego entre a nossa rede sairia pelo túnel 10.0. "src-ip" – máscara da origem "dst-port" – máscara da porta de destino "src-port" – máscara pra porta de origem "proto" – máscara do protocolo "all" . o valor do tráfego será a somatória de todas as estações.0/16 to any out via <device> add 2000 add pipe 20 all from 192. Você deve ter percebido que nós especificamos as máscaras em hexadecimal ao invés de decimal nos túneis. src-ip.0.168. que especifica todos os bits nos campos (dst-ip. O túnel 10 define a máscara 0x000000ff pros endereços de origem.com. Se nós simplesmente direcionarmos todo o tráfego pra um túnel. mas uma delas nós vamos discutir posteriormente.freebsdbrasil. vamos assumir a mesma idéia anterior de uma rede atrás de um firewall onde cada estação deve ter uma banda de 100Kbit/s.máscara geral. As máscaras podem ser de seis tipos distintos: "dst-ip" – máscara pro IP de destino do pacote que esta sendo enviado pelo túnel. ou seja a máscara *deve* fazer menção ao endereço de origem. Por exemplo. A primeira questão que deve nos prender atenção no momento é que cada túnel define uma máscara diferente. Existem dois motivos pra termos túneis pra entrada e pra saída do tráfego. e não valores individuais. 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. simplesmente porque a regra 1000 direciona todo o tráfego que sai (out) pela rede interna. se comparadas. dessa maneira limitando a banda de forma separada. As duas notações funcionam perfeitamente. As máscaras pros túneis funcionam exatamente da mesma forma que as 'netmasks'. porque cada origem faz diferença quando queremos filas distintas pra cada estação que origina o fluxo. Pra utilizar máscaras pras estações às quais o tráfego deve ser separado por filas específicas. mas a utilização delas se torna muito mais clara quando nós percebemos que sua aplicação é definida de forma reversa. de forma http://www. O túnel (pipe) 20 definiu os mesmos valores de bandas e fila (queue) pro nosso conjunto de endereços de destinos. Da mesma forma o tráfego que está chegando (in) deve ser separado em filas (queue) disntas de acordo com cada endereço de destino. Quando nós utilizamos 'netmask' nós estamos dividindo a rede em subgrupos.IPFW­HOWTO   estações que pertencem a mesma rede. No túnel (pipe) 10 nós criamos uma limitação de banda de 100Kbit/s e fila de 10Kbytes pro endereço de origem do nosso conjunto de estações.

O valor em hexadecimal que nós especificamos corresponde à mascara decimal 0. http://www. Em 99% dos casos.0. a partir da regra seguinte. Então se você quer definir 254^2 estações na rede que o firewall vai estar controlando. Todo tráfego definido como “in” é o que entra pelas interfaces pra máquina firewall. ou seja. a máscara deverá ser redefinida. Fluxo do Tráfego pelo Firewall. Pra fazer isso basta desativar a seguinte opção no sysctl(8): net. Remanejamento de Pacotes por Túneis (Packet Reinjection).inet. Quando uma regra redireciona o tráfego pra um túnel sem usar “in” ou “out”.com. Isso implica em algumas consequências. Uma breve ilustração: _________ | REDE INTERNA <== REDE INTERNA ==> (OUT) | (IN) | | (IN) <== INTERNET | (OUT) ==> INTERNET | ________ | firewall | Reprodução integral ou parcial permitida desde que as fontes originais sejam mencionadas. Só pra constar .-) 8. uma pra rede verdadeira (Internet) e duas pra redes internas. Vamos lembrar que as regras que não especificam se o pacote deve ser examinado na entrada ou saída pelo firewall (usando as opções “in” e “out”). porque cada túnel roteia os dados de trás pra frente em relação à rede. imagine seu gateway com múltiplas interfaces de rede.255. Se vem das redes locais pro gateway.0. aí a máscara teria que ser 0. é a configuração definida pro túnel que toma parte do pacote.0. É claro que estamos supondo aqui que a rede em questão não deverá ter mais que 254 estações. Aqui nós definimos os bits altos como os últimos bits da máscara. Bem simples portanto: o último octeto indica que apenas uma estação será atribuída por fila (256 menos 255 = 1). mesmo depois de ter sido direcionado pro túnel. a regra será duplicada.fw.255. 7. e nesse momento a busca nas regras termina. serão sempre verificadas pro tráfego de entrada *E* de saída. como de costume no ipfirewall(4). ou seja. quando as regras não são definidas por interface (usando “via”) todas as regras são aplicadas à todas as interfaces.freebsdbrasil. Outra coisinha. Isso define que qualquer endereço com um único bit diferente entre os dois últimos octetos (ou seja os 16 últimos bits baixos) deverá ter sua própria fila de pacotes. simplesmente porque. ”out”).IPFW­HOWTO   que os bits iniciais são os bits altos. os bits imutáveis da subrede. ENTRA pelo firewall.one_pass: 1 Essa opção é booleana. mas caso existam. se vem da internet pro gateway. Contudo você pode forçar que o pacote seja reinjetado (ou remanejado) no firewall. Dessa forma é atribuida uma fila específica por controle de banda pra cada endereço de estação com número distinto (no seu último octeto).br . mesmo se definidos entrada e saída (“in”.255 (0000ffff).ip.2. assim que um pacote é direcionado à um túnel (pipe). ENTRA pelo firewall.3. um túnel pros pacotes que saem e um pros que entram.

porque existe um número menor de regras à serem processadas. Eis a segunda rasão que nós estávemos devendo pra se ter duas regras. Cada um é exemplificado com regras de firewall e uma explicação breve de como a regra funciona. Por isso filtramos os pings externos antes de verificarmos as regras dinâmicas.inet.123.18.0/24 como a local.18.freebsdbrasil.0/24 in via xl0 icmptypes 8 add 1010 allow icmp from 12. Se o tráfego de entrada e saída são direcionaos pro mesmo túnel.18. enquando a solução Stateful permite resposta apenas das estações que foram pingadas. ou seja. pro tráfego que entra e pro que sai. add add add keep-state add 1000 deny icmp from any to 12. xl0 será a interface de rede externa e xl1 será a interna. P) Como eu bloqueio pings externos.ip. Se você esta trabalhando com conexões de rede que sejam full-duplex portanto é sempre recomendado criar túneis distintos.0/24 in via xl0 icmptypes 8 1010 check-state 1020 allow icmp from 12. .123.0/24 to any out via xl0 icmptypes 8 1030 deny icmp from any to any O motivo pra regra de negação antes da regra com check-state é que as regras dinâmicas são bi-direcionais.com.123. que é de 5 segundos de vida pra cada regra. add 1000 deny icmp from any to 12. dessa forma podendo rotear as duas direções ao mesmo tempo. durante a vida últil da regra. então a vantagem de uma solução ou outra depende de uma análise da frequência que os pings ocorrem.18.br Reprodução integral ou parcial permitida desde que as fontes originais sejam mencionadas. conforme definidas na RFC http://www.fw.IPFW­HOWTO   Devemos também notar os conceitos de half-duplex e de full-duplex pras conexões. As regras dinâmicas pros pacotes ICMP usam as definiçoes do net. mas. os pedidos de echo podem vir de estações externas que serão permitidos. P) Como eu bloqueio que as redes privadas.18.18. A vantagem é que sobrecarrega menos o firewall. mas permito que eu possa pingar qualquer estação externa? R) A solução Stateful. simplesmente porque o túnel não pode rotear o tráfego em ambas as direções ao mesmo tempo. Nos nossos exemplos vamos adotar a rede 12. uma pra controlar cada direção de fluxo.123. então ele vai adotar um coportamento half-duplex. Apêndice A: Exemplos de Configurações de Firewall.123.0/24 in via xl0 icmtypes 0 Outra desvantagem da solução Stateless é que ela vai sempre aceitar respostas de echo (Echo Reply) de qualquer estação. A solução Stateless. A vantagem da solução Stateful é que as respostas de echo são permitidas apenas das máquinas que você pingou. Vamos ilustrar aqui alguns cenários onde é necessário implementar um firewall. elas sobrecarregam o firewall quando não existem muitas ocorrências de tentativas de pings.dyn_short_lifetime no sysctl(8).0/24 to any out via xl0 icmptypes 8 add 1020 allow icmp from any to 12.123.

IPFW­HOWTO   1918. R) Essa é a solução 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.123. http://www.0.0/24 to any out via xl0 keep-state add 1300 allow icmp from 12.0/24 in via xl0 add 1200 allow tcp from 12.168.123. ainda.0/24 to any out via xl0 setup keepstate state add 1200 allow udp from 12. quero também evitar que qualquer estação externa inicie conexões com as estações na minha rede.freebsdbrasil. dessa forma ninguém vai poder rodar nenhum tipo de servidor.0/24 to any out via xl0 add 1100 pipe 20 all from any to 12.0/12 via xl0 10. 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.16.0/16 to any via xl0 any to 192.123.123.16.18.0/24 in via xl0 icmptypes 8 add 110 check-state add 1000 pipe 10 all from 12.0.0/24 to any out icmptypes 8 keepadd 65535 deny all from any to any Reprodução integral ou parcial permitida desde que as fontes originais sejam mencionadas.0.18.0.0/8 to any via xl0 any to 10.18.com.18.168.18.0.123.0/12 to any via xl0 any to 172.18.123.0/8 via xl0 O) Como eu posso forçar a limitação de taxas de cada estação na minha rede de forma individual? Eu quero forçar um limite de UpStream de 64Kbit por segundo e DownStream de 384 Kbit por segundo pra cada estação.0.0/16 via xl0 172.0.0.br .

Master your semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master your semester with Scribd & The New York Times

Cancel anytime.