IPFW HOWTO.

Transcrição

1 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 é:

2

3 V.0.3br_pt Se existirem perguntas ou comentários, por favor, envie-os para A versão mais recente desse documento vai estar sempre disponível em Os direitos de reprodução desse documento são reservados. Versão em português desse documento sob responsabilidade de Patrick Tracanelli e Maurício Goto A versão mais recente do mesmo estará sempre disponível em Sumário. 1. Informacoes gerais sobre a Filtragem de Pacotes de Rede 2. Acionando o Ipfirewall(4) 2.1. O /etc/rc.firewall e firewalls com política aberta (OPEN firewalls) 2.2. Carregando Rulesets (conjunto de regras) Tipos de Firewall pré-definidos Tipos de Firewall Personalizado 3. Sintaxe de regras básicas do Ipfw(8) 3.1. Listando Regras Ativas 3.2. Comandos básicos e suas funções 3.3. Especificando Protocolos 3.4. Especificando endereços de Origem e de Destino Uma introdução à Netmask e Bitmask Especificando Portas e Faixas de Portas 4. Sintaxe de regras avançadas do ipfw(8) 4.1. A ação "unreach" 4.2. Controle de Interface e de Fluxo 4.3. Combinando tipos de pacotes ICMP e TCP específicos icmptypes tcpflags, setup & established ipoptions 4.4. Reconhecendo Pacotes Fragmentados 4.5. Filtragem baeada em UID e GID 5. Logs (Logging) 5.1. Propriedades de Logs 5.2. Configurações de Logs do sistema Opções do Kernel

4 Configurando o syslog(8) Configuração do newsyslog(8) pra fazer rotacionamento de logs (log rotation) 5.3. Configuração de log nas regras 6. Introdução à filtragem 'Stateless' e 'Stateful' de pacotes 6.1. Configurações 'Stateful' Iniciais 6.2. Configurações 'Stateful' Avançadas 6.3. Anatomia de uma Regra Dinâmica 7. Traffic Shapping (controle de tráfego) 7.1. Probabilidade de Ocorrências (Probability Matching) 7.2. Dummynet Reinjection) Enfileiramento de pipes (Pipe Queues) Máscaras de pipes (Pipe Masks) Remanejamento de pacotes por pipes (Packet 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.

5 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. 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:

6 kldload ipfw && \ ipfw -q add 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 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

7 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 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), ecoando informações sobre atividade dos pacotes pro syslogd(4), em cada regra que tiver a opção "log" definida. Vamos aborda-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 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, 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.

8 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): ${fwcmd} add 100 pass all from any to any via lo0 ${fwcmd} add 200 deny all from any to /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 ( ). 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 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 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 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

9 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 pro nosso capíulo 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) 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) 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: "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 , 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

10 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 Esse tipo de firewall vai permitir tráfego de , 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 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. 3. Sintaxe de regras básicas do Ipfw(8);

11 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 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 deny log logamount 100 tcp from any to / deny log logamount 100 tcp from any to / allow tcp from any any deny all from any to any Dessa forma, ainda que, a regra número 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 Fri Sep 21 06:31: deny log logamount 100 tcp from any to / Tue Sep 18 00:33: deny log logamount 100 tcp from any to / Sat Sep 22 19:12: allow tcp from any any 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 bloqueou um pacote foi na madrugada do dia anterior, a regra 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

12 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 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. 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

13 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. "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 /24 to /24

14 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 /24 (origem) pra rede /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 /24 to any Essa regra faria com que todo o tráfego vindo da rede /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 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 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 para qualquer outra estação. Sempre que um pacote coincidir com uma regra do

15 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 /16 to any add 2100 deny all from any to : A primeira regra permite todo o tráfego de pacotes vindo da rede cujo conjunto de endereços IP começa em até 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 ( ) 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 , 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 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 até ) 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 : add 1000 deny all from not 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

16 e e ^3 (256^3) (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: /28 O primeiro detalhe ao qual atentamos é que o endereço da rede é , então sabemos que a subrede inicia nesse valor, ou seja, o endereço de rede é 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: = , portanto a faixa de endereçamento IP varia de até ; 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

17 sempre 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 add 1100 allow tcp from any to add 1200 allow tcp from any to ,22,23 add 1300 deny udp from any to :8 Na primeira regra, todos os pacotes TCP cujo destino é a porta 25 da estação 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 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 é permitida. E, finalmente na quarta regra, todos os pacotes UDP destinados pra faixa de portas de 1024 à 1028 na estação 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, restandonos 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 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. 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

18 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 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 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,

19 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 quaisqueres, o seguinte seria o suficiente: add 1100 allow all from any to any in via xl0 Ou talvez, se você tiver um sistemas com 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: 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 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 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: 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)

20 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 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" 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)