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

IPFW FreeBSD

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@free.bsd.com.br) e Maurício Goto (freebsd-brasil@uol.com.br). A versão mais recente do mesmo estará sempre disponível em http://free.bsd.com.br/~eksffa/freebsd/ipfw.php 1

Sumário 1. Informacoes gerais sobre a Filtragem de Pacotes de Rede 03 2. Acionando o Ipfirewall(4) 04 2.1. O /etc/rc.firewall e firewalls com política aberta (OPEN) 05 2.2. Carregando Rulesets (conjunto de regras) 06 2.2.1. Tipos de Firewall pré-definidos 06 2.2.2. Tipos de Firewall Personalizado 07 3. Sintaxe de regras básicas do Ipfw(8) 08 3.1. Listando Regras Ativas 08 3.2. Comandos básicos e suas funções 08 3.3. Especificando Protocolos 10 3.4. Especificando endereços de Origem e de Destino 10 3.4.1. Uma introdução à Netmask e Bitmask 11 3.4.2. Especificando Portas e Faixas de Portas 12 4. Sintaxe de regras avançadas do ipfw(8) 13 4.1. A ação "unreach" 13 4.2. Controle de Interface e de Fluxo 13 4.3. Combinando tipos de pacotes ICMP e TCP específicos 14 4.3.1. icmptypes 14 4.3.2. tcpflags, setup & established 15 4.3.3. ipoptions 15 4.4. Reconhecendo Pacotes Fragmentados 15 4.5. Filtragem baeada em UID e GID 16 5. Logs (Logging) 17 5.1. Propriedades de Logs 17 5.2. Configurações de Logs do sistema 17 5.2.1. Opções do Kernel 17 5.2.2. Configurando o syslog(8) 18 5.2.3. Configuração do newsyslog(8) pra fazer rotacionamento de logs (log rotation) 18 5.3. Configuração de log nas regras 19 6. Introdução à filtragem 'Stateless' e 'Stateful' de pacotes 21 6.1. Configurações 'Stateful' Iniciais 21 6.2. Configurações 'Stateful' Avançadas 22 6.3. Anatomia de uma Regra Dinâmica 25 7. Traffic Shapping (controle de tráfego) 27 7.1. Probabilidade de Ocorrências (Probability Matching) 27 7.2. Dummynet 27 7.2.1. Enfileiramento de pipes (Pipe Queues) 28 7.2.2. Máscaras de pipes (Pipe Masks) 29 7.2.3. Remanejamento de pacotes por pipes (Packet Reinjection) 30 8. Fluxo do Tráfego pelo Firewall 31 Apêndice A: Exemplos de Configurações de Firewall 32 2

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. Um firewall costuma ser arquitetado de diversas formas, mas todas as maneiras podem ser simplificadas com base em duas políticas de filtragem: aberto e fechado. O Firewall que segue uma política aberta permite que todos os pacotes sejam roteados por padrão, e bloqueia aqueles que pertencem a um tipo de conexão que não é desejado, ou seja, "abre tudo e bloqueia os indesejados". Já o firewall que segue uma política fechada, faz o inverso, bloqueando todo o roteamento de pacotes, e libera um a um o tráfego de conexões permitidas. Essa segunda implementação proporciona um firewall muito mais rígido, contudo sua configuração é bem mais trabalhosa, porque você pode facilmente bloquear o tráfego de algum serviço que esteja sendo utilizado na rede. Alguns protocolos estabelecem conexões dinâmicas, que são bem mais difíceis de se prever, mas você tem como estar atento a esse tipo de situação. 3

2. Acionando o Ipfirewall(4); 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, e compilar um novo kernel pro seu sistema; ou você pode usar o kldload(8) pra carregar dinâmicamente o módulo base do ipfw(8), o ipfw.ko, no kernel. As duas abordagens funcionam bem pra adicionar um firewall(4) com configurações básicas, contudo, a compilação estática proporciona, com pouca diferença, uma melhor performance, mas permite ainda que se adicione opções mais detalhadas de configuração, como por exemplo, a geração e limitação de logs. Pra carregar o ipfw de forma dinâmica, simplesmente use o comando: root@eeviac~# kldload ipfw root@eeviac~# Pra acionar o ipfirewall(4) de forma estática, 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, logo após a próxima inicialização do sistema. Contudo, as coisas não são tão simples quanto parecem, se você simplesmente seguir os passos descritos acima quando estiver na frente da máquina, vai perceber que existe a necessidade de algumas opções adicionais pra poder usar a estação. Se você prestar atenção nos conceitos de política de firewall citados acima (aberto e fechado), vai entender porque o uso do equipamento vai se complicar muito, se você não perceber que o firewall usa uma política padrão fechada. Se você simplesmente adicionar o ipfirewall(4) sem nenhuma configuração posterior, todo o tráfego de rede vai ser bloqueado, ou seja, nenhum pacote será roteado. Isso fatalmente pode se tornar um tormento se você for adicionar o firewall remotamente. É claro que esse tipo de dor de cabeça pode ser evitada, mesmo considerando que não é recomendado acionar o ipfirewall(4) remotamente, tanto de forma estática quanto dinâmica. Se, de qualquer maneira, você quiser carregar o ipfirewall(4) de um computador remoto, então recomendados que se faça da seguinte forma: root@eeviac~# kldload ipfw && \ ipfw -q add 65000 allow all from any to any root@eeviac~# Assim você vai automaticamente adicionar uma regra pra permitir todo o tráfego da rede, ao invés de bloquea-lo, evitando assim que você perca a conexão com a máquina remota. De qualquer forma, é recomendável que se carregue o ipfirewall(4) dessa maneira em máquinas locais também, especialmente se elas estiverem conectadas em rede, pra não perder uma conexão em andamento. Acionar o ipfirewall(4) no kernel, de forma estátita em uma máquina remota, contudo, requer um pouco mais de trabalho. O motivo é simples, quando você termina de instalar um novo kernel, você é obrigado a rebootar a sua máquina, ai sim, a partir da próxima inicialização ela irá utilizar o novo kernel. Contudo se você somente adicionar o ipfirewall(4) no kernel, assim que o sistema estiver no ar, ele não vai estar roteando os pacotes, ou seja, você não vai conseguir estabelecer uma conexão remota novamente com a máquina. 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 que assim você não seja bloqueado pelo seu próprio firewall. Pra você fazer isso, basta adicionar duas linhas no seu rc.conf, uma que vai acionar o firewall na inicialização da máquina, e outra pra definir o tipo de firewall que vai ser iniciado. No caso firewall do tipo aberto (OPEN). Então basta adicionar as seguintes entradas no seu /etc/rc.conf: firewall_enable="yes" firewall_type="open" Existem ainda outros tipos de firewall previamente definidos no /etc/rc.firewall, mas nós vamos tratar deles posteriormente. Por enquanto vamos começar com uma política de firewall aberta (OPEN). Ainda existe uma alternativa muito boa pra se definir uma política aberta como padrão pro ipfw(8) no kernel. Você pode simplesmente adicionar a seguinte linha no arquivo de configuração do seu kernel: options IPFIREWALL_DEFAULT_TO_ACCEPT 4

Nesse caso, as opções que nós adicionamos no rc.conf anteriormente não serão *necessárias*, porque nós não vamos *precisar* do /etc/rc.firewall pra configurar uma política aberta de firewall, porque essa política já vai ser iniciada por padrão no kernel. Contudo, ainda que você escolha definir uma política de firewall padrão no kernel, é interessante adicionar aquelas opções ao /etc/rc.conf porque posteriormente nós vamos usar o /etc/rc.firewall pra carregar nossas próprias regras de configurações de firewall. Adicionar essas opções ao /etc/rc.conf também é válido se você vai carregar o kernel dinâmicamente, porque se eventualmente seu sistema for reinicializado, o módulo ipfw.ko não vai ser carregado de forma automática. As funções de carregamento do firewall pelo /etc/rc.conf permite-nos carregar o módulo ipfw.ko automaticamente. 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, até o início da série 4.x do FreeBSD algumas dessas opções não podiam ser acionadas se não fosse de forma estática no kernel, mas nas versões mais recentes foram definidas algumas variávies do kernel, mutáveis via sysctl(8), que não restringem mais essas opções ao kernel estático. Além do IPFIREWALL_DEFAULT_TO_ACCEPT nós ainda temos as seguintes opções: options IPFIREWALL_VERBOSE options IPFIREWALL_FORWARD options IPFIREWALL_VERBOSE_LIMIT=# A opção IPFIREWALL_VERBOSE permite logar o tráfego de pacotes com o ipfirewall(4), ecoando informações sobre atividade dos pacotes pro syslogd(4), em cada regra que tiver a opção "log" definida. Vamos abordá-la com mais detalhes posteriormente. A opção IPFIREWALL_FORWARD permite que os pacotes sejam redirecionados para outros hosts, utilizando o comando "fwd" do ipfirewall(4). Redirecionar o pacote (FORWARD) é fazer com que ele siga de um ponto específico (host, rede, porta) para outro. Vamos tratar desse assunto com mais detalhes ao longo do documento. A opção IPFIREWALL_VERBOSE_LIMIT=# define um limite de pacotes que serão logados para uma regra específica. Dessa forma, o syslogd(8) não será sobrecarregado com mensagens relativas à atividades do ipfirewall(4), 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, caso um possível ataque gere muitas ocorrências da mesma regra. O "#" deve ser substituído com o número de vezes que se deseje que as atividades de cada regra seja logada. Dessa forma, se definirmos, por exemplo IPFIREWALL_VERBOSE_LIMIT=100 (padrão), quando existirem 100 ocorrências da mesma regra, as informações sobre a atividade de pacotes daquela regra deixará de ser logada. Se você usa IPv6, as seguintes opções no kernel terão efeito correspondente sobre as ações do firewall quanto a pacotes IPv6: options IPV6FIREWALL options IPV6FIREWALL_VERBOSE options IPV6FIREWALL_VERBOSE_LIMIT=100 options IPV6FIREWALL_DEFAULT_TO_ACCEPT Pra habilitar as mesmas opções do ipfirewall(4) sem recompilar o seu kernel, você vai definir as variáveis correspondentes por meio do sysctl(8), por exemplo: eksffa@eeviac~# sysctl -w net.inet.ip.fw.verbose=1 eksffa@eeviac~# sysctl -w net.inet.ip.fw.verbose_limit=100 eksffa@eeviac~# sysctl -w net.inet.ip.forwarding=1 Ainda existem mais quatro opções relacioadas ao ipfirewall(4) que podem ser definidas no kernel, mas não serão discutidas no momento, porque não são necessárias para a implementação básica de um firewall. Essas opções envolvem situações mais complexas e específicas de roteamento de pacotes, e vamos tratar delas assim que começarmos a tratar essas configurações. 2.1. O /etc/rc.firewall e firewalls com política aberta (OPEN firewalls); Ainda que você defina ou não o tipo de firewall que você vai estar trabalhando, sempre que a opção firewall_enable="yes" é adicionada no rc.conf e o sistema é iniciado, o /etc/rc.firewall é lido e executado também, a partir das configurações definidas no rc.conf, e os seguintes comandos são sempre adicionados ao ipfw(8): 5

${fwcmd} add 100 pass all from any to any via lo0 ${fwcmd} add 200 deny all from any to 127.0.0.0/8 A variável ${fwcmd} é definida anteriormente no rc.firewall, implicando quando o ipfw(8) vai ser executado de forma silenciosa (opção -q) ou não. A primeira regra em questão, permite todo tráfego proveniente da interface de loopback (a lo0), e a segunda regra bloqueia todo o tráfego direcionado à rede localhost (127.0.0.0). A primeira regra é necessária pra permitir comunicação inter-processos locais (local IPC), e a segunda regra evita que qualquer pacote externo adentre o endereço de host local (localhost address), que é o endereço de loopback, protegendo assim o tráfego local. Se essas regras não existirem e o firewall tiver uma política padrão fechada, você vai encontrar problemas na inicialização de alguns serviços, especialmente serviços RPC(3), entre outros problemas. Por isso vale ressaltar a impostância de se definir o firewall da forma correta, onde o uso do /etc/rc.firewall via rc.conf é altamente recomendável. 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, você deve ficar atento a essas e outras regras que não devem faltar ao seu firewall. Em seguida, quando você define um firewall do tipo "OPEN" (aberto) no rc.conf, o rc.firewall ativa a seguinte regra no firewall: ${fwcmd} add 65000 pass all from any to any Essa regra permite que todo tráfego externo seja aceito como entrada (com excessão pro loopback, já que a rede localhost é previamente bloqueada) e todo o tráfego interno seja aceito como saída. A mesma função do IPFIREWALL_DEFAULT_TO_ACCEPT no kernel. Se a política aberta é definida no kernel, 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", posteriormente adicionando a regra número 65000. Isso cria uma redundância de política de firewall aberta. Então, é mais indicado definir o tipo de firewall como "UNKNOWN" (desconhecido) se você adicionou a política aberta (IPFIREWALL_DEFAULT_TO_ACCEPT) no kernel, e não quer permitir mais nenhuma regra do rc.firewall. Para isso, inclua as seguintes linhas no seu /etc/rc.conf: firewall_enable="yes" firewall_type="unknown" Se você quer simplesmente habilitar o firewall para trabalhar algumas regras e ver como o ipfirewall(4) do FreeBSD funciona, ou ainda, apenas bloquear alguns hosts específicos, e manter as suas configurações propícias às suas próprias regras, então você pode seguramente pular pra nossa seção 3. Contudo, se sua intenção é usar algum dos conjuntos de regras nativas já existentes no rc.firewall, ou criar seu próprio conjunto de regras, então as opções "OPEN" ou "UNKNOWN" não são suficientes. Então não pule pra seção 3 (lol). 2.2. Carregando Rulesets (conjunto de regras); 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.firewall, e a segunda é criar sua própria definição, com seu próprio conjunto de regras. Os autores do firewwall nativo do FreeBSD, ipfirewall(4), recomendam o segundo caso, por duas rasões simples: - Você pode customizar suas regras de firewall pra satisfazerem da melhor forma as suas necessidades, sem nunca tocar no rc.firewall, que pode ser mantido como uma referência geral sempre que você precisar. - Você vai ser obrigado a se familiarizar com o uso do ipfw(8) e sua sintaxe, se tornando mais experiente na definição de firewall, e ficando mais a vontade com o ipfw(8). 2.2.1. Tipos de Firewall pré-definidos; É óbvio que a decisão final é a do administrador da rede, ou do responsável pelo firewall, no caso você que está lendo esse documento. Se você preferir usar os conjuntos de regras de firewall prédefinidos no rc.firewall, então é recomendado que você leia todas elas, pra se tornar familiar e saber exatamente como cada tipo de firewall funciona, antes de ativar qualquer um dos tipos pré-definidos. O controle que gerencia qual definição de firewall carregar é feito pela opção firewall_type="" no rc.conf. Além de "OPEN" existem ainda mais 3 tipos de firewall disponíveis: 6

"CLIENT" - Essa definição de tipo de firewall (firewall_type) permite todo o tráfego proveniente da rede local (por exemplo, uma rede interna atrás de NAT) pra ela mesma. Bloqueia pacotes fragmentados, permite que mensagens de email, resoluções de nomes (DNS) e NTP sejam enviadas pra dentro e fora da rede, e não permite nenhuma máquina que esteja fora da rede interna iniciar conexões TCP com máquinas dentro da rede. 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. Esse tipo de firewall funciona com política aberta ou fechada, definida no kernel, ou seja, não faz diferença se você colocou IPFIREWALL_DEFAULT_TO_ACCEPT ou IPFIREWALL_DEFAULT_TO_DENY como padrão. "SIMPLE" - Esse tipo de firewall é uma contradição. Apesar do nome SIMPLE, ele é muito mais complexo que a definição CLIENT, 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. Essa regra vai evitar spoofing (técnica onde uma máquina se faz passar por outra, alterando seu endereçamento IP) não permitindo a entrada de nenhum pacote que tenha um endereço de retorno igual ao endereço de qualquer host dentro da rede interna. Vai bloquear todos os pacotes endereçados como de redes privadas, conforme definido na RFC 1928, evitando o tráfego pra dentro ou fora da rede, e vai bloquear ainda todas as redes nãoroteaveis, conforme definido no Internet-Drafts da IETF (disponível em http://www.ietf.org/internetdrafts/draft-manning-dsua-03.txt). Esse tipo de firewall vai permitir tráfego de e-mail, de WWW, de DNS, e NTP, e vai permitir também pacotes fragmentados, e em relação às conexões TCP iniciadas por hosts fora da rede, o firewall não vai apenas bloquear, como na definição CLIENT, vai também logar todas essas tentativas. "CLOSED" - Tecnicamente essa definição não é um conjunto de regras de firewall, porque não adiciona nenhuma regra. Na verdade, aqui acontece tudo que nós insistimos que você deve evitar, ou seja, estabelece uma política fechada, negando todo e qualquer tráfego da rede (exceto o tráfego via lo0 que nós vimos anteriormente que é controlado por padrão). Essa definição simplesmente desabilita todos os serviços IP na rede, a não ser que no seu kernel você tenha adicionado a regra de política aberta. Então, 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. Ou seja, não defina como padrão no rc.conf. 2.2.2. Tipos de Firewall Personalizado; Se você decidiu estabelecer um conjunto de regras customizado, então é recomendável que você especifique um arquivo, ao invés de um dos tipos de firewall abordados acima. A maneira de se estabelecer esse tipo personalizado de firewall é a mesma, utilizando a opção firewall_type no rc.conf, contudo, basta indicar o caminho (path) pro seu arquivo de regras: firewall_enable="yes" firewall_type="/etc/rc.firewall.rules" Dessa forma você vai poder definir sua própria configuração de firewall no arquivo /etc/rc.firewall.rules, o qual será carregado sempre que seu firewall for iniciado. Se você preferir ainda que seu firewall seja iniciado de forma silenciosa, basta incluir no rc.conf: firewall_quiet="yes" O formato do seu conjunto de regras será apresentado de forma um pouquinho diferente nesse arquivo, em relação ao que você encontra no rc.firewall. O motivo é simples, o rc.firewall é um 'shell script' sh(1) escrito de forma que possa rodar por si próprio, enquanto o arquivo que define as suas regras personalizadas estão ali simplesmente para serem processadas pelo ipfw(8). A principal diferença é que você não vai usar nada correspondente à variável ${fwcmd} usada no rc.firewall. Simplesmente as regras. Posteriormente, vamos construir um arquivo de regras próprio, e então vamos ver isso passo-a-passo. 7

3. Sintaxe de regras básicas do Ipfw(8); A sintaxe das regras de firewall no FreeBSD são simples. Qualquer regra pode ser adicionada pelo console, com o comando ipfw(8). Antes de nos aprofundarmos nas sintaxes das regras do ipfirewall(4), contudo, vamos verificar como podemos listar as regras que estão ativas no momento. 3.1. Listando Regras Ativas; A forma mais simples possível de se listar as regras ativas no firewall: root@eeviac~# ipfw list Dessa forma, você vai estar listando todas as regras ativas no momento, seguindo a ordem do número da regra. Por exemplo: root@eeviac~# ipfw list 00101 deny log logamount 100 tcp from any to 192.168.1.0/24 12345 00102 deny log logamount 100 tcp from any to 192.168.1.0/24 21 00103 allow tcp from any any 65535 deny all from any to any Dessa forma, ainda que, a regra número 00103 tenha sido adicionada antes da regra 00101, a de número menor será mostra antes, porque a ordem das regras também influi na forma como o ipfirewall(4) vai se comportar. Pra mostrar a data e hora da última vez que um pacote coincidiu com uma regra basta usar a 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.168.1.0/24 12345 00102 Tue Sep 18 00:33:12 2001 deny log logamount 100 tcp from any to 192.168.1.0/24 21 00103 Sat Sep 22 19:12:15 2001 allow tcp from any any 65535 deny all from any to any root@eeviac~# date Sat Sep 22 19:12:24 GMT 2001 Ou seja, nesse caso, a última vez que a regra 00101 bloqueou um pacote foi na madrugada do dia anterior, a regra 00102 bloqueou um pacote também aos 33 minutos de 2 dias atrás, e o último pacote permitido pelo firewall foi há 9 segundos. Detalhe no comando date posterior que ilustra a data corrente. Por último, se nós queremos listar o número de vezes que um pacote passou (ou foi bloqueado) por uma regra, e o número de bytes que esse tráfego gerou, podemos fazer o seguinte: root@eeviac~# ipfw -a list ou root@eeviac~# ipfw show Os dois comandos vão apresentar as mesmas informações, dispostas da mesma maneira. A primeira coluna é o número da regra, em ordem como ela é verificada. A segunda coluna informa quantas vezes aquela regra coincidiu com um pacote, seguido do (terceira coluna) número de bytes que trafegaram pela regra, e finalmente a regra em sí. Existem algumas sintaxes curtas pra esses comandos. Por exemplo, "ipfw s" tem o mesmo efeito que "ipfw show"; "ipfw l" o mesmo que "ipfw list", etc. 3.2. Comandos básicos e suas funções; A partir de agora nós vamos, gradualmente, analisarmos cada opção e comandos disponíveis pra se construir um conjunto de regras de firewall. Por enquanto não vamos abordar regras com as opções de stateful, ou seja, estaremos trabalhando com regras stateless. Durante os nossos exemplos, não vamos estar utilizando o programa de controle do firewall (o /sbin/ipfw), que deve preceder cada um dos nossos comandos, caso estejamos configurando as regras de forma manual, pelo console do FreeBSD. O 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.firewall" no rc.conf. 8

add 1000 allow all from any to any Esse é o exemplo mais simples de uma regra. Nós já encontramos a mesma regra anteriormente, com uma única diferença, que era o número da regra. Lembre-se que, na seção 2.1 quando nós discutimos sobre tipos de firewall "OPEN" (aberto) nós trabalhamos com o parâmetro "pass", que é como ele foi usado no rc.firewall. Bom, acontece que "pass", "allow" e "permit" são sinônimos pro ipfirewall(4), eles tem o mesmo efeito, 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. Nessa regra, "all" (todos) os pacotes vindos de "any" (qualquer) lugar para "any" (qualquer) destino são permitidos ("allow"). No ipfirewall(4), grande parte das vezes, sempre que um pacote combinar com uma regra, o ipfirewall(4) pára de examinar as outras regras pra aquele pacote, ou seja, a ordem como as regras são processadas no firewall do FreeBSD são do tipo "first match wins" onde, a primeira constatação do pacote evita que as outras sejam lidas. Por isso é extremamente importante estar atento a ordem (número) das regras. Sob circunstâncias especiais as outras regras podem ser procesadas. Então, de forma geral, 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". Uma simples tradução seria o suficiente pra explicar que "add" adiciona uma regra e "delete" a exclui. O <número da regra> varia de 0 até 65535, e indica a ordem que essas regras serão processadas no firewall, portanto a última regra sempre define a política padrão do firewall no kernel. Mesmo se você tiver uma política de firewall aberta (OPEN) definida no seu /etc/rc.conf, a última regra vai sempre indicar a política do kernel. Isso é ótimo porque, como a ordem de busca das regras para de processar ao encontrarem uma regra que combina com o pacote, e se a penúltima regra é a de número 65000, definida pelo rc.firewall pra permitir todo o tráfego da rede, então todo tráfego vai ser liberado, mesmo que a última regra (65535) negue todos os pacotes, já que essa regra nunca vai ser processada. "<ação>" na sintaxe do ipfw(8) pode ser uma das seguintes: "allow" "pass" "permit" "accept" - Quando uma regra define essa ação, sempre que um pacote combinar com essa regra, será permitido seu roteamento pelo firewall, e o processamento das regras *pra esse pacote* termina. "deny" "drop" - Qualquer pacote que combinar com uma regra cuja ação seja "deny" ou "drop" são silenciosamente bloqueados pelo firewall, e o processamento das regras pra esse pacote termina. add 1100 deny all from any to any Essa regra nega todos os pacotes vindos de qualquer origem e indo pra qualquer destino. "reset" - Quando um pacote encontra uma regra com essa ação, o pacote é bloqueado, e o ipfirewall(4) tenta enviar um sinal (flag) de TCP Reset (RST) pro endereço de origem do pacote. O processamento das regras pra esse pacote termina. Como esse tipo de regra apenas se aplica pra pacotes TCP, o protocolo especificado na regra deve ser "tcp", para que apenas tais pacotes sejam processados por essa regra, e não todos (proto "all") os protocolos de pacotes IP. Vale notar que o uso do "reset" pode ser muito interessante pra enganar ferramentas que escaneiam as redes (network scanners), já que normalmente podem detectar um serviço por trás de uma porta filtrada, mesmo que ele esteja por trás de um firewall de bloqueio. Por outro lado, 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, isso duplicaria o uso da sua banda de rede. Uma solução simples é bloquear, com uma regra prévia o endereço da máquina que está agindo dessa forma, endereço esse obtido de forma dinâmica por monitoramento. add 1200 reset tcp from any to any Essa regra 'precária' (risos) bloquearia todas as conexões TCP vindas de qualquer destino, indo para qualquer origem, e responderia com um pacote RST para cada uma delas. 9

"count" - Todos os pacotes que combinarem com uma regra cuja ação seja "count", determinará que o ipfirewall(4) incremente o contagem de pacotes, ou seja, a saída de "ipfw show" indicará mais uma ocorrência de pacotes nessa regra. Motivos estatísticos óbvios. O processamento das regras do firewall continuam a buscar por outras regras que combinem com os pacotes. add 1300 count all from any to any add 1310 count all from 200.230.50.0/24 to 192.168.1.0/24 Essa (primeira) regra incrementa o número de vezes que um pacote passou pelo firewall, vindo de qualquer lugar e indo pra onde quer que seja. Já a segunda regra conta quantos pacotes, dentre todos, estariam sendo enviados da rede 200.230.50.0/24 (origem) pra rede 192.158.1.0/24 (destino). Uma observação aqui: se o processamento das regras fosse terminado quando um pacote encontra uma regra cuja ação seja "count", então, no exemplo acima a regra 1310 não teria serventia alguma. "skipto <número da regra>" - 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. add 1400 skipto 1800 all from 192.168.1.0/24 to any Essa regra faria com que todo o tráfego vindo da rede 192.168.1.0/24 e indo pra qualquer destino seja processado pelas regras a partir da regra de número 1800 "reject" - Essa ação é pouco utilizada atualmente. Quando um pacote combina com uma regra cuja ação seja "reject", então o ipfirewall(4) bloqueia esse pacote e responde com uma mensagem ICMP do tipo "host unreachable", dando a impressão que a máquina se encontra fora da rede. Essa é uma forma não silenciosa de negar o tráfego pelo firewall, contudo, assim como a ação "reset", essa ação também aumenta o uso da sua banda de rede. 3.3. Especificando Protocolos; Protocolo (proto) em "protocolo" na sintaxe básica de uso do ipfw(8), é o protocolo de comunicação que você quer que aquela regra combine. Definições de protocolos do tipo "ip" ou "all" são especificações gerais que englobam todos os protocolos. Os protocolos mais comuns são "icmp", "udp" e "tcp", mas a relação de protocolos com os quais o ipfirewall(4) trabalha é enorme. Na verdade são todos os protocolos possíveis de uma rede. Para uma lista completa das possibilidades, fique a vontade: root@eeviacbsd~# cat /etc/protocols 3.4. Especificando endereços de Origem e de Destino; O endereço de destino e de origem de um pacote tem o mesmo formato em uma regra de firewall. Eles podem ser um nome, definido no /etc/hosts e resolvido por DNS, pode ser um endereço IP, um endereço de rede com máscara de rede (bitmask/netmask) e, ainda podem definir uma ou várias portas, se o protocolo for tcp ou udp. Usar nomes ou endereços IP é indiferente, basta atentar ao fato que a resolução de nomes via DNS pode mudar sem seu conhecimento prévio. add 1000 allow all from minhamaquina to outramaquina add 1100 deny all from 10.0.0.5 to any A primeira regra permite todo o tráfego vindo da "minhamaquina" para a "outramaquina", e a segunda regra nega toda conexão da máquina 10.0.0.5 para qualquer outra estação. Sempre que um pacote coincidir com uma regra do firewall, o processamento pra aquele pacote termina, e o pacote é permitido ou negado, de acordo com a ação definida pela regra. Esse é um exemplo muito simples de um filtro baseado em estações, ou "host-based filtering", que filtra de acordo com o destino ou origem do pacote. Um firewall por filtragem de redes funciona de forma similar, distinguindo-se apenas a notação de redes, onde é necessário definir a máscara de subrede (netmask) ou ainda o bitmask. Vejamos: add 2000 allow all from 192.168.0.0/16 to any add 2100 deny all from any to 10.0.0.0:255.0.0.0 10

A primeira regra permite todo o tráfego de pacotes vindo da rede cujo conjunto de endereços IP começa em 192.168.0.0 até 129.168.255.255. A regra usa uma máscara (bitmask) pra indicar a abrangência do endereçamento da rede. A máscara em bits também conhecida como bitmask especifica quantos bits do endereço de rede (192.168.0.0) devem permanecer o mesmo pra cada pacote. Nesse caso, os primeiros 16 bits dos 32 bits do endereço vão continuar os mesmos. Como os primeiros 16 bits são os primeiros dois octetos do endereçamento da rede, então todos os endereços cuja origem seja a indicada nos dois primeiros octetos (ou nos 16 bits iniciais), nesse caso a rede 192.168, serão permitidos por essa regra. A segunda regra tem uma função similar, utilizando as máscaras de rede. A máscara de rede (netmask) indica quantos bits do endereço de rede deve ser monitorado pelo regra do firewall. No exemplo acima, a segunda regra (número 2100) tem a máscara de rede 255.0.0.0. O primeiro octeto dessa regra é definido como 'bits altos', ou seja, os primeiros 8 bits são 'bits altos', o que indica pro firewall que apenas os pacotes cujos primeiros 8 bits do endereço da rede devem ser filtrados. Como os primeiros 8 bits da rede é igual a 10, então todos os pacotes cujo endereço de destino seja 10 no primeiro octeto (ou seja, toda a faixa de 10.0.0.0 até 10.255.255.255) vão combinar com essa regra, e então serão bloqueados, como indicado na ação da regra (deny). O firewall do FreeBSD oferece ainda a possibilidade de inverter a expressão apresentada na regra com o comando "not". Por exemplo, para que o ipfirewall(4) bloqueie todos os pacotes que não seja da estação 192.168.0.3: add 1000 deny all from not 192.168.0.3 3.4.1. Uma introdução à Netmask e Bitmask; O princípio básico que envolve máscaras de rede e bits de rede (netmask e bitmask) são simples, mas frequentemente confundidos por pessoas que não tenham muito conhecimento em redes, e ainda requer um pouco de noção de números binários. É muito mais prático se nós trabalharmos com endereço IP em sua forma binária, contudo, a confusão que existe entre os conceitos binários e decimais costuma ser decisiva pra alguém sem muitos conhecimentos em rede. De qualquer forma, para uma referência rápida, a seguinte tabela ilustra que faixa de endereçamento IP corresponde a qual bitmask e respectivo netmask em uma classe C de rede. Alguns breves exemplos de bitmask e netmask adicionais são ilustradas, denotando algumas definições pra redes maiores.... Bitmask Netmask Total de IPs IPs usáveis 32 255.255.255.255 1 1 31 255.255.255.254 2 1 30 255.255.255.252 4 2 29 255.255.255.248 8 6 28 255.255.255.240 16 14 27 255.255.255.224 32 30 26 255.255.255.192 64 62 25 255.255.255.128 128 126 24 255.255.255.0 256 254 22 255.255.192.0 16320 16318 20 255.255.128.0 32765 32766 16 255.255.0.0 65536 65534 12 255.128.0.0 8.388608+e6 8.388606+e6 8 255.0.0.0 256^3 (256^3)-2 0 0.0.0.0(todos IPs) 256^ 4 (256^4)-2 Como você pode ver existe um padrão definido. O número de endereço total de uma rede sempre sobra a partir da máscara que lhe foi atribuida, 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). O motivo também é simples, 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. O último octeto da máscara de rede (netmask) começa com 255 e sempre se decrementa em valores múltiplos de 2, enquanto o bitmask se decrementa em múltiplos de 1. Vamos ver, de forma sucinta como usar a tabela acima. Vamos descobrir então qual é a faixa de IPs que compõe uma subrede cujo endereço seja: 11

172.16.100.32/28 O primeiro detalhe ao qual atentamos é que o endereço da rede é 172.16.100.32, então sabemos que a subrede inicia nesse valor, ou seja, o endereço de rede é 192.16.100.32. Então percebemos que o bitmask do endereço é 28. Isso quer dizer que todos os primeiros 28 bits do endereço são 'bits altos', ou seja, são endereços que não mudam. Portanto, concluímos de forma lógica que temos apenas 4 bits ajustados como 'bits baixos', já que um endereço completo de rede tem 32 bits, e 28 são altos (conforme indicado pela bitmask) subtraindo 28 de 32 restam-nos 4 bits (os bits baixos). Sabemos agora que existem apenas 2 valores possíveis para cada bit, já que o endereçamento não decimal é binário. Então elevamos dois (possibilidades binárias) à quatro (bits): 2^4. Agora sim já temos o número de estações que aquele bitmask está indicando: 2^4 = 16. Agora basta somar: 172.16.100.32 + 16 = 172.16.100.48, portanto a faixa de endereçamento IP varia de 172.16.100.32 até 172.16.100.48; Se olharmos na tabela apresentada cima, veríamos que 16 endereços IP corresponde a um bitmask de 28, que é o nosso caso. Dessa forma poderíamos ter evitado todo esse cálculo matemático para encontrarmos o valor exato. Mas, vale lembrar que, nem sempre essa tabela vai estar disponível pra você consultar, a menos que você a imprima e ande com ela na carteira, portanto é muito mais valioso aprender como o endereçamento funciona e aplicar os cálculos necessários. Aprenda uma vez e use sempre. 3.4.2. Especificando Portas e Faixas de Portas; Você pode também controlar o tráfego de conexões baseando-se em filtragem de portas. 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. 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, simplesmente definindo a porta após o endereço. Uma faixa de portas pode ser especificada com um hífen, podem ser separadas por vírgula, ou ainda, em casos mais elaborados, pode-se usar um netmask pra definir a faixa de portas. É importante lembrar que você não pode definir "all" como protocolo na regra que especifica portas, porque nem todos os protocolos trabalham com portas. add 1000 allow tcp from any to 172.16.0.5 25 add 1100 allow tcp from any to 172.16.0.5 1021-1023 add 1200 allow tcp from any to 172.16.0.5 21,22,23 add 1300 deny udp from any to 192.168.0.5 1024:8 Na primeira regra, todos os pacotes TCP cujo destino é a porta 25 da estação 172.16.0.5 são permitidos pelo firewall. Na segunda regra todas as conexões TCP cujo destino seja qualquer porta da faixa 1021 até 1023 da estação 172.16.0.5 também são permitidas pelo ipfirewall(4). Na terceira regra, todos os pacotes TCP destinados às portas 21, 22 ou 23 na estação 172.16.0.5 é permitida. E, finalmente na quarta regra, todos os pacotes UDP destinados pra faixa de portas de 1024 à 1028 na estação 172.16.0.5 são bloqueados. A apresentação da faixa de portas na última regra é interessante, porque faz uso de uma netmask pra declarar a mesma. Mas a matemática também é bem simples. Como agora estamos tratando de Bitmask pra porta 1024, o valor pra ela é 10 bits, e como a máscara indica 8 bits, tiramos 8 possibilidades de 10, restando-nos apenas 2 bits. Como o valor de cada bit é binário, elevamos os bits disponíveis (2) aos valores possíveis (binário = 2): 2^2, então temos 4 portas que compõe a faixa de endereçamento da porta 1024, ou seja, de 1024 até 1024+4 = 1024 até1028. O uso de máscaras para definição de faixas de portas são raramente usadas, mas são bem mais interessantes do que o uso de bitmask ou netmask pra endereços IP, já que o número de bits de uma porta varia dependendo da porta em questão. Por isso o uso de hífen é recomendado pra se definir uma faixa de portas, e vírgulas quando se deseja definir várias portas em uma mesma regra. 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, e é estétitamente mais proveitoso. 12

4. Sintaxe de regras avançadas do ipfw(8); 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, ele se mostra solenimente curto pra muitas situações mais complexas, como por exemplo, 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, ou então que se queira um maior controle sobre o direcionamento do tráfego. Então, 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. Nós vamos inclusive cobrir uma nova "ação" que não foi relatada anteriormente. A Sintaxe pode parecer inicialmente confusa, mas nós vamos com calma, e montaremos as regras aos poucos. 4.1. A ação "unreach"; Primeiramente, vamos introduzir uma nova "ação": "unreach <código>" - Qualquer pacote que combine com uma regra cuja ação seja "unreach", serã respondido com um código 'ICMP unreach' (código ICMP de indisponibilidade), e posteriormente a leitra do conjunto de regras será terminada. As possibilidades de códigos pro 'ICMP unreach' pode ser indicada por número ou por nome. Segue agora uma breve lista de 'ICMP unreach codes' (os códigos em questão) e seus nomes correspondentes. Se você não sabe onde esses códigos são utilizados, não tem porque você tentar usa-los: net 0 net-prohib 9 host 1 host-prohib 10 protocol 2 tosnet 11 port 3 toshost 12 needfrag 4 filter-prohib 13 srcfail 5 host-precedence 14 net-unknown 6 precedence-cutoff 15 host-unknown 7 isolated 8 4.2. Controle de Interface e Fluxo; Uma das mais importantes funcionalidades do ipfw(8), que não foi comentada anteriormente na seção 3 desse documento é o controle de fluxo e de interface, ou seja, a possibilidade de criar regras que verifiquem os pacotes de acordo com uma interface em especial (aplicável quando você tem um sistema com múltiplas interfaces de rede). Essas regras podem identificar de onde esses pacotes estão vindo, e em que direção estão indo. Até agora o senso de direção que nós adotamos simplesmente definia os endereços de origem e de destino, 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, as opções "in" e "out" podem ser utilizadas com precisão. Ambas opções ("in" e "out") correspondem ao campo "interface-spec" no modelo de sintaxe dado anteriormente, e normalmente, são definidas próximas ao final de cada regra, antecedendo qualquer possível opção extra. Dessa forma, quando decidirmos filtrar todos os pacotes vindos de qualquer lugar e indo pra qualquer lugar, poderíamos definir: add 1000 allow all from any to any in Pra filtrar pacotes indo através de uma interface em particular, podemos usar a opção literal "via", seguida do nome da interface. Dessa forma, se estivermos usando uma placa de rede 3Com 3c59x PCI, sua interface será "xl0". Pra filtrarmos qualquer pacote, vindos especialmente dessa interface, com origem e destinos quaisquer, o seguinte seria o suficiente: add 1100 allow all from any to any in via xl0 Ou talvez, se você tiver um sistemas com múltiplas interfaces, e quiser filtrar todos os pacotes vindos de qualquer lugar e indo pra qualquer lugar, mas que esteja ao menos saindo via *alguma* interface, pode fazer o seguinte: 13

add 1200 allow all from any to any out via any Você vai notar que, quando você listar as regras de firewall, as entradas que estiverem usando "in" ou "out" combinadas com "via", não apresentarão a utilização do "via" mas apresentará a citação "recv" ou "xmit", dependendo da definição de um "in" ou um "out" respectivamente. Veja só: root@eeviac~# ipfw add 7000 allow all from any to any out via xl0 root@eeviac~# ipfw list grep 7000 07000 allow ip from any to any out xmit xl0 root@eeviac~# Portanto, você pode usar "recv" ou "xmit" no lugar de "via" quando você for criar alguma regra que faça uso de "in" e "out", contudo isso não é preciso, o ipfirewall(4) distingui se a interface está recebendo o transmitindo o dado, e, além do que, essa definição pode confundir usuários não experientes. No geral, essas opções oferecem muito mais controle sobre o tráfego da rede em um sistema de interfaces múltiplas, e qualquer outro sistema em geral, visto que elas permitem a filtragem de pacotes específicos vindo para o firewall, saindo por ele, e se deslocando através de uma interface especificada. 4.3. Combinando tipos de pacotes ICMP e TCP específicos; Pacotes ICMP, TCP e IP são apresentados em vários formatos distintos. Esses tipos de pacotes são definidos por várias _flags_ (opções de identificação). Nós podemos filtrar cada um desses tipos usando uma das seguintes opções do ipfw(8), ao final de cada regra: 4.3.1. icmptypes (tipos icmp); "icmptypes <tipo>" - Essa opção filtra o pacote ICMP do <tipo> definido, e inverte a opção se uma '!' (exclamação) for devinida antes do <tipo>, ou seja, todos os pacotes que não forem desse tipo serão combinados. Existe, atualmente 15 tipos diferentes de pacotes ICMP que podem ser filtrados; cada um é definido por um número. Você pode ainda especificar faixas de 'icmptypes' utilizando hífen ou separando-os por vírgula. Os 15 tipos de pacotes ICMP são: 0 - Echo Reply (Resposta de Echo) 3 - Destination Unreachable (Destino Indisponível) 4 - Source Quench (Origem extinta) 5 - Redirect (Redireção) 8 - Echo Request (Pedido de Echo) 9 - Router Advertisement (SPAM de roteamento? :-)) 10 - Router Solicitation (Pedido de Roteamento) 11 - Time-to-Live Exceeded (TTL Excedido) 12 - IP header bad (Cabeçalho IP malformado) 13 - Timestamp Request (Pedido de Timestamp) 14 - Timestamp Reply (Resposta de Timestamp) 15 - Information Request (Pedido de Informação) 16 - Information Reply (Resposta de Informação) 17 - Address Mask Request (Pedido de Máscara de Rede) 18 - Address Mask Reply (Resposta de Máscara de Rede) Se você ficou curioso pra saber como esses tipos ICMP, especialmente o tipo 3, correspondem aos códigos de indisponibilidade que podem ser criados com a opção "unreach", então, saiba simplesmente que o tipo 3 identifica qualquer um desses códigos, ou seja, todos. Usar filtros de pacotes ICMP é muito útil, especialmente pra controlar ping; por exemplo, você pode permitir que qualquer cliente dentro da sua rede interna pingue qualquer estação pra fora da rede, enquanto você bloqueia que qualquer estação externa pingue o seu gateway, ou qualquer outro cliente interno. 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. A segunda permite que todos os pacotes icmp do tipo 0 (resposta de echo) entrem 14

pelo firewall, e a regra seguinte bloqueia todos os pacotes icmp do tipo 8 de entrarem. Em resumo, permite que qualquer cliente faça um pedido de echo pra fora, e permite a entrada da resposta pra dentro do firewall, e não permite que ninguém de fora faça um pedido de echo pra dentro do firewall, ou seja, todomundo protegido pelo firewall pode pingar qualquer estação externa, mas ninguém de fora pode pingar dentro. Naturalmente essas opções só podem ser definidas quando o protocolo da regra for "icmp". 4.3.2. tcpflags, setup & established; "tcpflags <flag>" - Essa opção filtra qualquer pacote TCP cujo cabeçalho contenha alguma das flags (opções) identificadas. Uma definição inversa também pode ser utilizada se colocarmos uma '!' (exclamação) antes da <flag>, dessa forma filtrando todos os pacotes TCP que não possuam a <flag> em questão. 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, concordância com a conexão) urg - Indicate Urgent OOB data (indica um OOB de dados urgentes) A <flag> SYN é a mais interessante, visto que ela é enviada quando uma conexão TCP é iniciada. Por ser tão importante, existe inclusive uma opção separada do ipfw(8) dedicada especialmente pra definir pacotes TCP cujo cabeçalho tenha a flag SYN ajustada. Essa opção se chama "setup". É claro que só podemos trabalhar com a opção "setup" quando o protocolo indicado é o "tcp". "setup" - Qualquer regra contendo essa opção vai filtrar todos os pacotes TCP cujo cabeçalho indique a flag SYN ajustada. Dessa forma, se quizermos simplesmente negar todos os pacotes TCP que estiverem entrando no firewall com o cabeçalho SYN definido, 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, a mesma ação é tomada: todos os pacotes TCP SYN vindos de qualquer (any) origem para qualquer (any) destino serão negados. Vale a pena ilustrarmos a necessidade do protocolo ser "tcp" quando trabalharmos essas regras. "established" - Exatamente como existe uma opção especial que identifica um pedido de inicialização de conexão TCP ("setup"), existe também uma opção que identifica quando uma conexão já está estabelecida, ou seja, ja foi iniciada. Pela grande importância de facilitar o controle de conexões TCP, as opções "established" e "setup" foram disponibilizadas, dessa forma oferecendo facilidade na criação de regras. Utilizando estas opções (ou mesmo suas definições nativas correspondentes às "tcpflags") podemos ter inicialmente um controle de conexões TCP mais simples. Essa é a base de implementações "stateful" de um firewall. Vamos trabalhar com elas de forma mais detalhada depois. 4.3.3. ipoptions; "ipoptions <flag>" - Finalmente podemos trabalhar com alguns pacotes IP específicos. A <flag> que define um tipo de pacote IP é nomeada SSRR (para: Strict Source Route), LSRR (para: Loose Source Route), RR (para: Record Packet Route), e TS (para: Timestamp). Se você não sabe pra que serve cada uma dessas flags, então não haverá necessidade de construir regras que façam uso delas. 4.4. Reconhecendo Pacotes Fragmentados; Pacotes fragmentados podem ser filtrados com a opção "frag" do ipfw(8). Na grande maioria dos casos, os pacotes fragmentados devem ser bloqueados pelo firewall. Receber um número grande de pacotes fragmentados pode indicar a eminência de um ataque do tipo DoS (Denial of Service - ou Negação de Serviço). Mesmo considerando que o FreeBSD, e a maioria dos outros sistemas UNIX de verdade não são sucetíveis a esse tipo de ataque, os sistemas Windows são frequentemente muito vulneráveis. Dessa forma, se você tem clientes Windows por trás do firewall, dentro da sua rede, é recomendável bloquear pacotes fragmentados pra protege-los. Quando você for usar a opção "frag" pra filtrar (e bloquear) os pacotes fragmentados, tem duas regrinhas básicas que você deve seguir. A primeira é que você não pode usar "frag" quando também estiver usando a opção "tcpflags"; você define qualquer pacote fragmentado, ou não define nenhum. A segunda: você também não pode utilizar o "frag" se estiver especificando portas TCP ou UDP; você bloqueia todos os pacotes fragmentados, não importando pra qual porta ou serviço eles estejam sendo 15

enviados. Dito isso, podemos facilmente definir uma regra pra negar todos os pacotes fragmentados que estiverem entrando na rede: add deny all from any to any in frag 4.5. Filtragem baeada em UID e GID; Uma poderosa função que outros firewall (como o IPFilter) não possuem é a filtragem de pacotes baseada em GID/UID. O Ipfirewall(4) tem a capacidade de filtrar pacotes de acordo com o UID ou GID do dono do processo o qual originou uma conexão. Por motivos lógicos só se pode filtrar pacotes que tenham sido gerados por processos locais. 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. Um uso em potencial dessa função é restringir o número de IPs virtuais em um servidor de shell. 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, você pode definir uma regra baseada em filtragem de UID, para que, dessa forma, 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.16.0.10 in add allow tcp from 172.16.0.10 to any out uid patrick add deny tcp from 172.168.0.10 to any Essas regras permitem que apenas o usuário 'patrick' vai poder utilizar a alias de IP (Apelido de IP, IP-Alias ou IP vhost) 172.168.0.10 pra estabelecer conexões TCP pra fora da rede. Ninguém mais será permitido pendurar Bots, Clientes de IRC ou qualquer outra coisa que precise estabelecer conexão TCP (quase tudo) nesse endereço IP. O protocolo UDP também pode ser usado para filtragem de pacotes baseada em UID/GID, contudo nenhum outro protocolo fora esses dois podem. Outra utilização possível pra UID/GID seria habilitar limitação de uso de banda para cada usuário, ao invés de limitar pra cada estação ou rede. Por exemplo, você pode definir um grupo de usuários que tenham contas rápidas de FTP, definindo uma regra pro GID em questão, e em contrapartida ter um grupo de usuários de shell que não precisam de muita banda. Vamos ilustrar outras limitações de bandas definidas por GID posteriormente, quando estivermos cobrindo o "traffic shaping" com ipfirewall(4). Por motivos de segurança, talvez seja necessário voce logar o tráfego de rede de um usuário em particular, e nesse caso o filtro baseado em UID/GID também viria bem a acalhar. Na verdade sempre que se queira definir um comportamente distinto do firewall com base no usuário que acessa o serviço, o UID/GID do ipfw(8) sempre vem bem a acalhar. Uma pequena dica é sempre definir as regras baseadas em UID/GID antes das outras regras, visto que o ipfirewall(4) termina a verificação da lista das regras quando um pacote combina com alguma das regras em uso. Isso garante desempenho e evita que se bloqueie ou permita um pacote antes de verificar qual usuário originou o tráfego. 16

5. Logs (Logging); 5.1. Propriedades de Logs; As vantagens de manter os logs do firewall ativo são óbvias. A possibilidade de verificar posteriormente quais conexões foram negadas, de que endereços elas vieram, pra que rede ou estação elas estavam indo, se o conteúdo dos pacotes eram fragmentados (indicantivo de muitos ataques de negação de serviço DoS), enfim, possibilita saber onde as conexões estão sendo feitas, por quem e quando. Em especial, os logs de firewall são importantes pra rastrear crackers ou pessoas má intencionadas. Mas logar também tem o seu lado negativo, se você não for cuidadoso. Dependendo do tipo de dado que você está logando você pode se perder com a abundância de mensagens, e também utilizar muito espaço em disco pros arquivos de logs. Ataques de negação de serviço que tendem a sobrecarregar discos rígidos é um dos tipos mais antigos de atividade má intencionada, e por incrível que pareça ainda é sinônimo de perigo pra administradores imprudentes. Por isso a importância de se definir que tipos de regras serão logadas. Normalmente logar pacotes permitidos de serviços públicos (como WWW) não é uma boa indéia, visto que o próprio serviço (servidor WWW) também mantém logs das atividades de acesso, e a frequência de pacotes em um serviço como esse é muito grande. Por outro lado, o que a maioria dos novos administradores que experimentam quando eles habilitam o ipfirewall(4) pra logar, é o seu terminal abarrotado com mensagens sobre a atividade de pacotes. Esse pequeno inconveniente é o resultado da combinação de: - estar logando regras que combinam com pacotes muito frequentes; - não ter desabilitado logs pro console e pros terminais de root (péssima idéia); - não estar controlando limite de logs com o IPFIREWALL_VERBOSE_LIMIT; 5.2. Configurações de Logs do sistema; 5.2.1. Opções do Kernel; Pra habilitar os logs do ipfirewalll(4) no FreeBSD, 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, quando estavamos revendo a ativação do firewall. Essa segunda opção do kernel limita o número de mensagens consecutivas enviados ao sistema de logs do FreeBSD, o syslogd(8), quando dada regra do firewall é ativada. Portanto, quando você aciona essa opção no kernel, o número de mensagens consecutivas relacionada a uma conexão em particular é limitada ao valor (número) específico. Considere o seguinte: options IPFIREWALL_VERBOSE_LIMIT=10 Com essa entrada definida no seu kernel, apenas 10 mensagens consecutivas a respeito de determinada conexão serão logadas no syslogd(8), 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), você terá que editar o /etc/syslog.conf. O syslog.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. O limite definido pra IPFIREWALL_VERBOSE_LIMIT fica à critério do administrador, mas valores acima de 10 já proporciona um tráfego alto de mensagens em servidores muito requisitados. Mas se você quer definir um arquivo separado pra logar tudo de forma distinta, ao invés de simplesmente logar no arquivo padrão (/var/log/messages), isso pode ser feito também, e ainda, 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. 17

5.2.2. Configurando o syslog(8). Você pode configurar o syslogd(8) pra logar as atividades do ipfirewall(4) em um arquivo separado, seguindo três passos relativamente simples: 1) Crie o seu novo arquivo de log para o ipfw(8) e, como alternativa, crie também o diretório de logs que você achar conveniente. Vamos assumir então que você quer que todos os logs relativos ao ipfirewall(4) sejam armazenados em /var/log/ipfw/ipfw.log. Dessa forma você vai ter que criar o diretório em questão (/var/log/ipfw) e em seguida o arquivo de log (ipfw.log) sob tal diretório, pra isso vai utilizar o comando touch(1): eksffa@eeviac~# mkdir /var/log/ipfw && touch /var/log/ipfw/ipfw.log eksffa@eeviac~# Tenha certeza que o diretório e arquivo em questão não tenham permissões de leitura pra outros usuários senão o dono do arquivo, por questões óbvias de segurança. 2) Configure o syslog.conf(5) pra enviar todas as mensagens relativas ao ipfirewall(4) pro arquivo /var/log/ipfw/ipfw.log. A forma mais fácil de fazer isso é adicionar as seguintes linhas no final do syslog.conf(5):!ipfw *.* /var/log/ipfw/ipfw.log Atente pra usar <TAB> (tecla tab) nesse arquivo ao invés de espaços simplesmente. Mesmo assumindo que usar "tabs" não é obrigatório no FreeBSD pro arquivo /etc/syslog.conf, é de bom costume fazê-lo, caso você trabalhe também com outros UNIX, cuja maioria não aceita espaços no syslog.conf(5). Portanto mesmo você podendo ignorar a mensagem de advertência no início do /etc/syslog.conf, é sempre bom manter o bom hábito seguro de usar o syslog.conf(5) da forma indicada por ele. Você vai reparar que as mensagnes do tipo "last messages repeated # times" (ou seja: últimas mensagens repetidas # vezes) serão também logadas, além desse arquivo, pra qualquer outro cujo syslog.conf(5) aponte as seguintes entras: *.err, kern.debug, *.notice E ainda, o console também irá receber todas essas mensagens, como definido na linha: *.err;kern.debug;auth.notice;mail.crit /dev/console Lembre-se que o console na verdade é apenas o ttyv0 (ALT+F1). Os consoles virtuais e pseudo terminais se comportarão de forma distinta em relação à mensagens. Por padrão as seguintes linhas definirão quando as mensagens forem enviadas pra outros terminais: *.err root *.notice;news.err root *.alert root *.emerg * As linhas *.err e *.notice irão logar mensagens do kernel e também as exibirão no terminal onde o usuário especificado estiver logado. Note que o usuário em questão é o 'root', então, como por padrão você não deve logar como root a toa, o usuário root será sempre alertado. Não se recomenda de forma alguma que essas linhas sejam comentadas, 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. Se por bom senso você costuma estar muito logado com outro usuário que não seja o root, também é considerável configurar o syslogd(8) pra alertar o seu usuário. Então vamos resumir o que deve ser feito quando você for configurar seus logs pelo arquivo de configuração syslog.conf(5): Insira a linha com "!ipfw" e indique o caminho pra onde as informações referentes às atividades do Firewall devem ser logadas. Não altere as mensagens que serão enviadas ao usuário Root se ele estiver logado. Indique os mesmos alertas pra um usuário que você usa com mais frequência. 3) Envie um sinal de reinicialização pro processo do syslogd(8). A forma mais fácil é usando o comando: eksffa@eeviac~# killall -HUP syslogd eksffa@eeviac~# 5.2.3. Configuração do newsyslog(8) pra fazer Rotação (ou Rotacionamento) de Logs (log rotation); Agora que o ipfirewall(4) está configurado pra logar todas suas atividades, você deveria pensar seriamente em configurar o newsyslog.conf(5) de forma a garantir que o newsyslog(8) vá rotacionar os logs do ipfirewall(4), ou, como alternativa, optar por algum outro mecanismo de rotacionamento de logs. 18

Pra se ter uma boa noção de todas as configurações possíveis do newsyslog.conf(5) é recomendado que você leia a página de manual (man newsyslog.conf) do arquivo. Essa é uma poderosa ferramenta de logs, mas não tem porque nós explicarmos ela aqui, isso é tarefa pra um capítumo sobre administração do sistema FreeBSD, pro nosso caso de Firewall específico a seguinte entrada deve ser o bastante: /var/log/ipfw/ipfw.log 600 10 * $W0D2 Z Essa linha pode ser adicionada no final do arquivo newsyslog.conf(5). A primeira entrada é um tanto quanto óbvia, ela indica qual arquivo vai ser rotacionado. A segunda indica os bits de permissões pros arquivos rotacionados. A terceira parte é o número de arquivo de logs que se deseja manter rotacionando até que o mais antigo seja apagado. O seguinte é o tamanho do arquivo quando ele deve ser rotacionado, não estamos usando essa opção. A quintar parte é quando (tempo) nós devemos rotacionar o arquivo, e finalmente a última opção, é uma opção especial. Como você já deve ter concluído, rotação de logs são definidas por dois critérios: tamanho ou data. No nosso caso, nós indicamos que queremos que o arquivo de log seja rotacionado às duas da manhã de todo domingo, não importando o tamanho do arquivo de log. Depois definimos (a última opção especial, "Z") que o arquivo deve ser comprimido com gzip(1) sempre que rotacionar, e definimos que vamos manter um histórico arquivado de 10 semanas. Se você deseja manter seus logs por mais que 10 semanas basta alterar o valor 10 pra qualquer um que você queira. Ou o ideal, criar uma rotina que faça backup em uma máquina separada (um LogHost) a cada 10 semanas, ou então gravar seus Logs em CD ou qualquer outra mídia barata e de grande capacidade quando for necessário. Uma vez configurado, o newsyslog.conf(5) vai cuidar do rotacionamento dos logs do ipfirewall(4). O newsyslog.conf(5) é ativado pelo cron(8) do FreeBSD, e por isso não precisa de um Daemon rodando, consequentemente você não tem que reiniciar nenhum processo. Você pode criar seu próprio script pra rotacionar logs ou usar de terceiros, com tanto que você confie. De qualquer forma é bom decidir uma maneira de controlar o crescimento dos logs dentro do seu sistema. Lembre-se, não existe nada que o cron(8) e um script não possa fazer nesse caso. 5.3. Configuração de Log nas Regras; Uma vez que tudo esteja pronto pra utilizar as funções de logs do ipfirewall(4), vamos começar a definir quais regras nós queremos logar quando elas forem filtradas. Existem dois parâmetros básicos pra usarmos em conjunto com nossas regras pra definirmos que queremos logar *aquela* regra. Vejamos: "log" É o parâmetro mais comum. Toda vez que uma regra que for definida o "log" for acionada, então a ação definida ("action") por aquela regra será logada todas as vezes que um pacote coincidir a regra. 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, então imagine a frequência de informações que serão logadas sempre que cada pacote for permitido pelo seu firewall. Esse tipo de regra pode facilmente proporcionar problemas pro seu disco local ;-) Por outro lado, definir "log" pra uma regra geral de negação é uma pedida considerável: add 65000 deny log all from any to any Essa regra é mais considerável, porque é uma das últimas, em uma política clara de firewall do tipo "CLOSED" ou seja, tudo que deve ser permitido já o foi nas regras anteriores que suponhamos existir, portanto nos interessa manter logs das conexões negadas. Além do que o número da regra é 6500, o que, em relação à regra anterior (500) é muito mais seletiva, visto que é uma das últimas regras a serem checadas. Preste muita atenção pra escolher quais regras você quer logar e quais você não quer. "logamount <número>" - Esse parâmetro em seguida ao "log" define o número máximo de vezes que uma regra vai ser logada. Esse parâmetro é análogo à entrada de limite de verbosidade no kernel, e da muito mais controle ao administrador que pode, por exemplo, definir um número baixo pra uma determinada regra, e zerar a mesma uma vez ao dia, dessa forma só deixando de logar o período que um possível ataque ocorrer. Essa definição é possível no FreeBSD 4.x, FreeBSD 2.2.x e FreeBSD série 3 acina de 3.4.x. Nas versões anteriores à 3.4 no FreeBSD 3.x o padrão do "logamount" era 10. Sempre que uma regra é logada, as informações geradas pra tal pacote são: - Data & Hora 19