Firewal com FreeBSD (PF)

Instalação

Para ter maior facilidade na captura das telas e controle sobre o ambiente (evitando que problemas de hardware compliquem nosso tutorial) estou usando uma máquina virtual montada no VMware Workstation 6.5 no período de avaliação , com duas placas de rede (uma ligada ao adaptador da sua rede real, e outra ligada a uma rede "interna" do VM, um HD de 8 GB e 512 MB de memória. Não tenho conhecimento/experiência suficiente para discutir os pré-requisitos de hardware,  com certeza aqueles que conhecem bem vão achar um exagero esta configuração que coloquei, mas como a intenção é mostrar a instalação e configuração, por favor, me perdoem.




Como o tutorial não é sobre virtualização vamos direto ao BSD. Coloque o CD de instalação do BSD no drive (ou monte a imagem no dispositivo virtual), de o boot por ele e vai se deparar com essa tela (figura 1):

Figura 1 - Tela de abertura

Aqui basta um [enter], que acionara a opção default que é a número 1. Na tela seguinte, você vai escolher o país (e como nem tenho a pretensão de que terras não tupiniquins façam uso do tutorial, escolham “Brazil”, número 31.

Figura 2 - Seleção de país

Mais um [enter] e vamos para a escolha do teclado. No nosso caso, o teclado adotado é um US-Internacional e por isso vamos escolher o USA ISO. Mas para quem usa os teclados ABNT2 (com “ç”) usem BRAZIL ISO (accent).

Figura 3 - Configuração de teclado

A próxima tela (figura 4) já é a do sysinstall, um utilitário do BSD que auxilia na parametrização do Sistema Operacional, como queremos ser o mais prático possível, vamos seguir a instalação da forma mais simples possível, mas é importante ressaltar que você pode fazer uso do sysinstall mesmo depois da instalação do BSD, e acredite, você vai fazer! Para seguir adiante, escolha a opção Standart, e teclando [enter].

Figura 4 - Menu principal do sysinstall

Você vai receber uma mensagem avisando que você terá um menu do tipo “DOS”, ou seja, um menu um pouco menos amigável do que estes que você encontrou até agora, mas não entre em desespero “ainda”, são duas ações simples e automáticas. Não desista agora, tecle [enter] e vamos ao particionamento do disco.

Figura 5 - Aviso de troca de ambiente (DOS-Style)

Apesar de um pouco assustadora (não tanto quanto as telas azuis do Windows) basta você teclar [a] e depois [q]. O que você estará fazendo com isso é optar pelo uso do disco inteiro (A – Use Entire Disk) e finalizar as alterações no esquema de particionamento (Q – Finish).

Figura 6 - Antes de [a]

Figura 7 - Depois de [a] e pronta para [q]

As figuras 6 e 7 representam respectivamente o estado que você deve encontrar seu disco (no caso dele não estar particionado e o que você provavelmente vai encontrar após teclar [a]. Naturalmente é possível criar outras partições (slice como é chamada no BSD) ou mesmo trabalhar com partições já existentes. Isso fica pra quem se habilitar a montar um tutorial mais elaborado, boa sorte e não esqueça de me mandar uma cópia.

A figura abaixo (figura 8) mostra a próxima tela, aonde você escolhe de que forma vai gerenciar o boot do seu servidor.  A opção BootMgr (Boot Manager) é mais para o caso de múltiplos sistemas operacionais (ou mesmo partições) , já a opção Standart (que será a nossa escolha) faz o registro de boot no MBR, com certeza menos flexível, mas para nosso caso (um único SO na maquina) é a escolha certa.

Figura 8 - Métodos de boot

Novamente um [enter] para seguirmos adiante (com Standart selecionado) e recebemos um novo aviso sobre as partições BSD dentro do slice (figura 7) criado. Mais uma vez vamos optar pelo processo automática, e confiarmos na sabedoria do instalador do BSD, aqui basta um [enter] para uma nova tela “DOS”.

Figura 9 - Particionamento

Muito parecida com a primeira interface “DOS” que vimos, esta também conta com uma opção de [a] (Auto Defaults. Logo que clicarmos em [a] o instalador vai sugerir uma “divisão” do espaço reservado para a instalação, que para o caso de utilização de um único disco geralmente satisfaz. Para seguirmos adiante, mais uma vez o [q] para finalizarmos.

Figura 10 - Antes do particionamento [a]

Figura 11 - Depois do particionamento [a]  pronta para [q]

A tela seguinte de instalação permite que você escolha um “tipo” de instalação, o que nada mais é do que um conjunto pré-definido de pacotes. A opção 8 (User) traz uma instalação acompanhada dos binários do SO e de sua documentação, o que para nós está mais do que na medida. Aponte o cursor para 8 e [enter].

Figura 12 - Escolha da distribuição

A tela que segue pergunta a você se deseja instalar a “Coleção Ports”. Vamos responder que sim, pois o “Ports” é uma das maneiras mais simples e otimizadas para instalar aplicativos no FreeBSD, se você quiser conhecer mais sobre ele, acesse http://www.freebsd.org/ports/. Cliquem em [Yes] e vamos em frente.

Figura 13 - Escolhendo o Ports

Alis, “em frente” não é a melhor expressão a ser usada, por que vamos voltar para a tela da Figura 12, mas você vai perceber que a opção 8 está marcada ([x]). Agora você vai para a primeira opção da lista (Exit) e tecla [enter]. A tela que vai se apresentar em seguida é para escolher a forma de instalação que você quer.

Figura 14 - Instalação por FTP

Faça a escolha de acordo com o que for melhor pra você. A instalação através do CD do BSD é rápida, pois ele faz tudo localmente, eu particularmente sempre uso a instalação por FTP, e vou seguir o tutorial nesta mesma linha. Acredito que não haja muita diferença das outras formas, então os que tiverem um bom link de internet, (nem precisar ser tão bom assim, tenho um ADSL 2M da BRT e vai bem obrigado.

Para quem optar pela instalação através da internet, vai se deparar com uma tela perguntando que “repositório” deseja usar, eu sempre uso a primeira opção de “Brazil” (ftp.br.freebsd.org) e nunca precisei garimpar outra, mas os mais neuróticos podem fazer um ping para alguns e analisar qual seria o mais rápido.

Figura 15 - Escolhendo o repositório

Após escolhermos o repositório o instalador pergunta qual interface de rede que vamos usar para estabelecer a conexão com a internet. Não posso fazer muito para ajudar, visto que a identificação da placa pode mudar de acordo com o fabricante, etc... Então, boa sorte, mas acho que não será muito problema, afinal, você esta montando um servidor firewall. Vou aproveitar para ressaltar o seguinte, estou montando esse tutorial da forma mais didática possível, e acredito que até o menos experiente usuário conseguirá chegar no resultado final, todavia, a experiência com segurança digital é algo que requer tempo e muita cautela.

Quando você escolher a interface de rede, o instalador fará duas perguntas pra você: primeiro se deseja ativar o suporte a IPV6 (http://portalipv6.lacnic.net/pt-br/ipv6/introdu-o/o-que-ipv6) e se desejar usar DHCP para configurar sua placa de rede. Para a questão do IPV6 diga não, pois não é “AINDA” uma realidade, e você usará somente o IPV4. No caso do DHCP, você terá que fazer essa avaliação, o DHCP é o serviço que fornece a um computador as configurações TCP/IP desta rede de forma automática, então, se você dispõe deste serviço diga que sim. Mas é possível, mesmo tendo o DHCP ativado em sua rede fazer a configuração de forma manual, mas para isso você terá que saber um numero IP livre em sua rede, o netmask dela, gateway e DNS basicamente.

Figura 16 - Aviso do IPV6

Nesse tutorial vou optar por colocar “na unha” os dados de TCP/IP, então vou responder “não” também para a questão DHCP. Naturalmente que os dados vamos usar não necessariamente serão os mesmos que você deve colocar, alias, pouco provável que seja. Se não souber o que significam estes campos, ou mesmo, com que valores deve preenche-los, entre em contato com o responsável pela rede que você usa, ele com certeza poderá fornecer os dados corretos.

Figura 17 - Aviso DHCP

Figura 18 - Configurações manuais de TCP/IP

Se tudo correr bem, o instalador vai requisitar sua confirmação informando que a fase de coleta de dados acabou, e que agora vai começar a instalar o SO no disco. Ele avisa que daquele ponto em diante, não haverá mais como se arrepender, que vai efetuar as alterações de disco e partição. Em fim, não espere uma babá te consolando se fez algo errado, recomendo que tome muito cuidado caso esteja tentando fazer a instalação em um disco com outros SOs. Coragem!!! Vamos adiante.

Figura 19 - Última chance

Esse ponto é um divisor de águas de nossa instalação, se você fez tudo certo, vai ter a companhia de uma tela como a Figura 20 por alguns bons minutos, caso contrário, recomendo começar tudo de novo, com bastante atenção. Mais uma vez aproveitando a deixa, reforço que este tutorial não tem por objetivo ensinar FreeBSD, mas fornecer um passo a passo para uma solução pontual, então, se quiser se aventurar em "tunnar" a instalação: Boa Sorte e não esqueça de mandar umas dicas.

Figura 20 - Instalação em andamento

Enquanto aguarda, aproveite o tempo e veja alguns endereços importantes como suporte:

• http://www.freebsd.org/ports/
• http://www.freebsd.org/docs.html
• http://www.google.com.br

Antes que me perguntem o que tem haver o Google com isso, acredite, você vai ter que fazer muita pesquisa por lá.

Se tudo correr bem, a próxima tela do instalador para você será um aviso de que a instalação está concluída, e que, caso você queira voltar ao sysinstall, ele estará disponível em /usr/sbin/sysinstall.

Figura 21 - Final da instalação

Podemos dizer que a instalação por si só já está terminada, agora o BSD vai fazer uma série de perguntas, para operacionalizar algumas coisas de forma automática, nós vamos optar por não na maioria delas, para tomarmos conhecimento do que e como estamos fazendo.


Pós intalação

A primeira pergunta é se esta máquina será um gateway na rede. Sim, ela será, mas não queremos que o BSD faça isso automaticamente para nós, deixaremos isso para a configuração do firewall em PF. Então responda [No].

Figura 22 - Habilitar gateway?

Em seguida você será inquirido sobre habilitar o inetd e serviços de rede que ele fornece, também optaremos por [No].

figura 23 - Habilitar inetd e serviços de rede?

Agora vamos fugir da resposta padrão [No] e vamos optar por [Yes] quando perguntado se desejamos habilitar o login por SSH. Imagino que os interessados nesse tutorial devam saber que SSH é o Secure Shell, um programa e um protocolo que permitem conexões remotas com mais segurança.

Figura 24 - Habilitar SSH?

Você será perguntando se deseja habilitar o FTP anônimo neste computador, nossa resposta é não. Vale comentar que não há razão alguma para ter o serviço de FTP em um firewall, tão pouco permitindo um login anônimo.
Acho oportuno comentar aqui que quanto menos serviços rodarem em um firewall menor será a chance dele ser invadido. Você vai encontrar muitas opiniões distintas sobre o assunto, tem administradores que mantém o servidor web, o gerenciador de Banco de Dados na mesma máquina firwall com squid, dns e PF, outros acham muito temeroso manter serviços como o Apache e MySQL em uma máquina responsável pela segurança.

Acho que se realizarmos uma reflexão mais tranqüila sobre o assunto, facilmente vamos concluir que cada caso é um caso. Na rede que aplicamos originalmente este firewall (a motivação para este tutorial) temos 250 estações bombardeando a internet com tráfego, o servidor WEB tem uma carga bastante intensa também, por que comporta além do website institucional uma série de outros sítios e aplicações administrativas.

Eu preferi manter o servidor WEB separado, a decisão é sua. Em relação ao tutorial, não vai implicar em nada muito diferente, talvez um pouco mais de cuidado na separação das partições, mas ainda assim o caminho é o mesmo.

Voltando ao nosso foco, para próxima tela, responda não, não queremos login anônimo de ftp.

Figura 25 - Habilitar FTP anônimo?

Outras duas indagações são sobre NFS (http://www.ime.usp.br/~carvalho/monografia-sad/node13.html), perguntando se deseja que esta máquina seja um servidor NFS, em seguida se deseja que ela seja um cliente NFS. No nosso caso, vamos responder [No] para ambas.

Figura 26 - Servidor NFS

Figura 27 - Cliente NFS

A customização da console se refere a coisas como protetor de tela, teclado e etc, nada que nos interesse neste momento, então, mais um não [No].

Figura 28 - Configurações da console

Na seqüência o que temos é o ajuste de fuso horário, e está vamos responder sim.

Figura 22 - Fuso horário

Agora a pós-instalação pergunta se está  maquina tem seu relógio (hardware/bios) ajustado para UTC, normalmente isso não deve ser uma realidade, e você pode responder não [No] para seguir ajustando as configurações de “time zone”. Se você tiver a sua disposição o recurso, não se acanhe, responda [Yes].

Figura 30 - UTC

O ajuste é bem intuitivo, você vai indicar a região mundial (America – Noth and South),

Figura 31 - Região

O país.

Figura 32 - País

Região no país.

Figura 33 - Região do país

Para confirmar a configuração o sistema pergunta se a abreviação BRST (no caso acima) parece “razoável”, e no nosso caso, sim.

Figura 34 - Confirmando

Agora o questionamento é um pouco mais complexo, e vale ao menos apontar a vocês este um link - http://www.freebsd.org/doc/en/books/handbook/linuxemu.html. O “Linux binary compatibility” é um recursos para rodar aplicações desenvolvidas para Linux, de um modo mais grosseiro vamos chamar de emulador de Linux. O raciocínio para responder essa pergunta é:  vai rodar algo neste servidor que não tenha uma versão para BSD? No nosso caso Não [No], mas fica aqui a atenção para este assunto, mas não se preocupe, se futuramente surgir a necessidade, você tem como instalar isso através do ports (/usr/ports/emulators/linux_base).

Figura 35 - Compatibilidade binária Linux

Vamos responder sim [Yes] na próxima pergunta para informarmos que temos um mouse instalado no computador.

Figura 36 - Mouse

Respondendo sim, será apresentada uma tela para configuração do dispositivo, escolheremos “Enable” e assim faremos o teste do dispositivo.

Figura 37 - Habilitando e testando o mouse

Movimente o mouse então, e veja se aparece um cursos, mesmo no modo texto, e responda sim ou não.

Figura 38 - Mouse - teste

Ele vai retornar para a tela da Firgura 37, ai basta escolher “X – Exit” para continuar o processo. Em seguida vai perguntar se você gostaria de navegar agora pelos pacotes do ports, como comentamos anteriormente, o objetivo é fazer tudo o mais na “unha” possível, então também vamos responder não.

Figura 39 - Navegação no Ports

Vai perguntar se deseja adicionar uma conta de usuário ao sistema. Isso já faz parte da segurança do sistema, pois não é nada aconselhável você trabalhar somente com o usuário root. Se você optar por trabalhar por SSH, verá que por padrão a conta root nem é aceita para login. Vamos responder sim [Yes] e adicionar um usuário - basta escolher "User" após responder [Yes].

Figura 40 - Adicionar um usuário ao sistema

Em “Login ID:” informamos o identificador para o usuário, ou como sempre chamamos, o login. Os campos UID e Group não precisam ser alterados nem preenchidos. No campo password você informa a senha que este usuário adotará, no campo “Full name” o nome completo do usuário. “Home directory” e “Login Shell” também não serão alterados, mas atenção, é muito importante que o campo “Member groups” receba a palavra “wheel". Este grupo wheel identifica os usuários que poderá fazer uso do comando “su” (Super Usuário), que transforma a sessão comum em uma sessão de root. Quando criar outro usuário para o sistema, que não deve ter privilégios de administrador, não o inclua neste grupo. No endereço http://www.openit.com.br/freebsd-hb/securing-freebsd.html você consegue mais detalhes sobre isso.

Figura 41 - Tela para edição do usuário

Em seguida, o sistema informa que você deve atribuir uma senha para o usuário root. Mesmo sendo um assunto bastante “manjado”, não usem senhas fracas, procurem usar números, letras, caracteres especiais, maiúsculas e minúsculas. Lembrem-se que estamos falando da porta de entrada da sua rede, melhor, da TRANCA de entrada da sua rede. No endereço http://idgnow.uol.com.br/seguranca/firewall/idgcoluna.2006-08-18.5368218714/IDGColuna_view você encontra uma boa orientação para a composição de sua senha, mas se ainda quiser saber mais, não esqueça do oráculo (clique aqui).

Figura 42 - Aviso da senha de root

Não se assuste com a saída do ambiente de instalação, essa tela azul que aparece não deve ser associada a do outro $i$tema Operacional. Não é um erro, mas uma pausa no instalador para que você digite por duas vezes a senha de root. Observe que o prompt está no final da tela.


Figura 43 - Tela da senha do root
(essa tela fico devendo, perdi em algum momento entre a edição PDF e essa conversão para Blog)

Após acertar a senha de root, o instalador pergunta se deseja ter uma visão geral da configuração para fazer algum ajuste. Nesse ponto usuários experientes podem contribuir, mas no nosso objetivo isso passará batido, vamos responder não  [No] e seguimos em frente.

Figura 44 - Visão geral da instalação (configuração)

Voltaremos para a tela inicial do sysinstall, como se nada tivesse acontecido, mas não se assuste, seu freeBSD está instalado e pronto para funcionar.

Figura 45 - sysinstall

Basta escolher “Exit Install”, remover o CD da unidade e responder a sim [Yes] na próxima pergunta.

Figura 46 - Reboot

O sistema vai reinicializar e apresentar a tela de boot do BSD, mas agora não a partir do CD e sim do SO instalado no disco. Um [enter] para seguir o boot e você vai cair na tela de login. Informe o usuário “root” e a senha que você atribuiu para se “logar” no servidor.

Figura 47 - Tela de login

Antes de seguirmos com a configuração do servidor, vale um comentário, se você optar por trabalhar remotamente através de SSH, deve fazer o login com o usuário “comum” que você adicionou (Figura 43), e depois disso usar o comando “su –“ para tornar-se “root”.

Os dois primeiro passos que vamos dar é a atualização do ports, para garantir que tenhamos a nossa disposição a ultima versão dos softwares que escolhermos instalar nesse servidor, para isso execute dois comandos, primeiro “portsnap fetch” que vai apresentar uma tela como a que segue. Você deve aguardar o download dos pacotes do ports, o que pode variar o tempo dependendo do seu link.

Figura 48 - Atualizando o Ports (1a. Parte)

Em seguida, execute “portsnap extract” para descompactar os pacotes que foram “baixados” pelo fetch.

O freeBSD conta com outro recursos para a instalação de aplicativos, bem mais rápido que o ports, mas menos flexível, pois o ports compila localmente o aplicativo instalado. Estamos falando do pkg_add. Então para instalarmos o VIM (VI melhorado) usaremos o comando “pkg_add –rv vim”. Antes com chovam uma centena de e-mails dizendo que existem muitos outros editores mais amigáveis vai minha dica: praticamente toda distribuição UNIX/LINUX vem nativamente com o vi, então se você se habituar com os comandos deste editor, provavelmente nunca ficará na mão em uma manutenção remota ou coisa parecida. Mas cada um na sua, escolha o editor que quiser e mãos a obra (/usr/ports/editors).

Figura 49 - Instalando o VIM

Outro aplicativo que vamos usar é o wget, o procedimento é o mesmo, execute o comando  “pkg_add –rv wget”. O processo é análogo a instalação do vim.

O wget será usado para copiar os arquivos que vamos disponibilizar neste tutorial, e acredite, vai facilitar muito a sua vida.

Antes de qualquer comando, execute um “rehash”, este comando fará com que as configurações sejam relidas, assim por exemplo o comando wget e vim estarão disponíveis para uso somente após o “rehash”.

O Vim conta com uma série de recursos legais, entre eles o “syntax highlight” que torna os arquivos editados coloridos de acordo com a função de cada palavra ou comando no arquivo. Ajuda muito. Mas para que estes recursos estejam ativados, é necessário que algumas configurações sejam feitas em um arquivo de configuração, no caso o /root/.vimrc ,  para facilitar, execute o comando:

fw# rehash
fw# wget http://suporte.ceart.udesc.br/bsd/vimrc.txt -O /root/.vimrc

Agora vamos editar o arquivo /root/.cshrc para incluirmos um alias para o vim, de tal forma que se digitarmos vi (a versão que acompanha o instalador) ele vai chamar o vim. Execute o comando vim /root/.cshrc e logo após as linhas de alias inclua a linha "alias vi      vim". Conforme a linha 13 da tela abaixo.

Figura 50 - Alias para vi

Evitando qualquer tipo de crucificação, quem quiser aprender com ousar o vim (que não é nosso objetivo nesse tutorial) acesse http://pt.wikibooks.org/wiki/Vim/Modos_de_operação para um resumo ou http://pt.wikibooks.org/wiki/Vim para o manual completo, que por sinal é muito bom.

Após alterar o /root/.cshrc você deve processar novamente o arquivo para que as alterações entrem em vigor, e para isso execute o comando source /root/.cshrc. Pessoal, apesar de estar comentando passo a passo cada ação que estamos fazendo, recomendo que leiam uma manual muito simples e completo feito pelo Centro de Comp. da Unicap, seu endereço original é http://ftp.unicamp.br/pub/apoio/treinamentos/unix/unix_basico.pdf, mas tomei a liberdade de colocar uma cópia aqui.

Firewall – Packet Filter

Quando falamos de Firewall em BSD estamos praticamente falando do PF (Packet Filter), uma poderosa ferramenta, que após o entendimento do seu conceito se torna muito fácil de administrar e organizar. Entre outras coisas chama-se a atenção para o Traffic Shaping (http://pt.wikipedia.org/wiki/Traffic_shaping) e as tabelas dinâmicas. No nosso tutorial não vamos explorar nem 1% da capacidade do PF, mas teremos um Firewall 100%  funcional.

Evoluir no PF é uma conseqüência. Antes de implementar BSD/PF o firewall utilizado por mim era baseado em DEBIAN e IPTABLES, e senhores, agüentando firme. Não se questiona também a eficiência desta dupla, nem quero desfazer de um servidor que segurou mais de 1 ano uma rede, sem sequer me dar ao trabalho de ler um arquivo de logs. A questão é que o PF se torna muito mais fácil de administrar, agora vou chamar atenção daqueles que tem um IPTABLES rodando, não tentem montar um arquivo do PF pensando como IPTABLES, vai penar muito, como eu penei (que o diga o Kassiano).

Para ativarmos o PF no freeBSD, basta adicionarmos a linha  pf_enable=”YES” no arquivo /etc/rc.conf, criarmos um arquivo (por enquanto vazio) /etc/pf.conf e rebootarmos o servidor.

fw# echo pf_enable=\"YES\" >> /etc/rc.conf

fw# touch /etc/pf.conf

fw# reboot

Antes de seguirmos adiante, observe a figura abaixo para visualizar a rede que estamos protegendo, abstraia os números IPs e aplique os dados da sua rede. Tomei a liberdade de deixar espaços em branco para que você possa anotar os dados referentes a tua rede.

Figura 51 - Diagrama da Rede

Com base nesse esquema, edite seu arquivo /etc/rc.conf incluindo a configuração de sua interface interna, provavelmente bastará você incluir uma linha parecida com:

 ifconfig_de1=”inet 10.10.1.1 netmask 255.255.255.0”

O arquivo deve ficar mais ou menos como:

Figura 52 - Modelo de rc.conf

Antes de montarmos um arquivo de configuração do PF, vou falar um pouco sobre o PF.

O Packet Filter é um firewall que nasceu para o OpenBSD, um Sistema Operacional “casaca grossa”, considerado o mais seguro do mundo, mas é portado para os outros SOs da família BSD, entre eles o FreeBSD. O PF atende praticamente todas as nuances de um sistema de firewall, ele tem funcionalidade para Load Balance (administrar o tráfego de interne em mais de um link), QoS (controle de qualidade de serviço, que permite reservar banda para determinados serviços), NAT (tradução de endereços) e RDR (Redirecionamento de portas entre redes).

O controle do PF é através do arquivo /etc/pf.conf, que é dividido em 7 partes, são elas:

• Macros
• Tabelas
• Opções
• Scrub
• Filas
• Tradução
• Regras de Filtragem

Apesar de que nem todas estas divisões sejam necessárias para o funcionamento do PF é importante que elas estejam nesta mesma ordem, exceto as macros e as tabelas, mas mesmo assim é fortemente recomendado que fiquem desta forma.

PF: Macros e Listas

Macros e Listas estão muito próximas umas das outras, uma lista nada mais é do que uma forma mais prática de agrupar endereços, que geralmente se aplicam à uma mesma regra (não haveria sentido se não fosse assim), veja o exemplo:
Vamos imaginar liberar na interface interna as requisições de SSH vindas do ip 10.10.1.10 para o próprio firewall, a regra ficaria algo como:

pass in quick on pcn0 proto tcp from 10.10.1.10 to 10.10.1.1 port 22          
Até ai, bastante simples, mas não é pouco comum, mais de um computador da rede interna ser liberado para acessar o firewall via SSH, então vamos incluir nesta necessidade mais três computadores (10.10.1.15, 10.10.1.32 e 10.10.1.45). Em um primeiro momento parece automático copiarmos e colarmos essa linha, substituindo os ip, o que funcionaria sem problemas, mas geraria um trabalho maior para manter o arquivo caso, por exemplo, alterarmos a porta de funcionamento do SSH. Para isso o PF implementa as listas, permitindo que a regra seja escrita assim:

pass in quick on pcn0 proto tcp from { 10.10.1.10, 10.10.1.15, 10.10.1.32, 10.10.1.45} to 10.10.1.1 port 22

Para o PF, ao processar o arquivo ele converterá de forma transparente a linha acima para:

pass in quick on pcn0 proto tcp from 10.10.1.10 to 10.10.1.1 port 22    
pass in quick on pcn0 proto tcp from 10.10.1.15 to 10.10.1.1 port 22    
pass in quick on pcn0 proto tcp from 10.10.1.32 to 10.10.1.1 port 22    
pass in quick on pcn0 proto tcp from 10.10.1.45 to 10.10.1.1 port 22    

É fácil observar a lógica de funcionamento e também perceber o quanto mais fácil fica de manter essa regra no caso da alteração da porta de funcionamento por exemplo. A aplicação de listas também é valida para portas ou protocolos, veja uma regra de DNS:

pass out quick on em0 proto { tcp, udp } from 10.10.1.0/8 to 208.67.222.222    

Mas as facilidades não terminam ai, vamos novamente supor que os computadores que acessam o firewall por SSH também tem o direito de acessar o servidor WEB diretamente, algo como:

pass out quick on em0 proto tcp from { 10.10.1.10, 10.10.1.15, 10.10.1.32, 10.10.1.45} to 192.168.1.5 port 80

Ainda usando nossa fértil imaginação, a administração da rede obrigou que o ip 10.10.1.45 fosse alterado para 10.10.1.44, seja lá por qual razão, ou ainda, algo muito mais provável de acontecer, por uma alteração de hardware, sua interface interna mudasse. Novamente teríamos dificuldades para mantermos as regras em que este ip ocorresse. Para isso resolvemos o problema com o uso de Macros, que nada mais são do que variáveis usadas nesse script de configuração, que ficaria assim:

if_int = “pcn0”

if_ext = “em0”

rede_int = “10.10.1.0/8”

ip_int = “10.10.1.1”

ip_ext = “192.168.1.1”

administradores = “{ 10.10.1.10, 10.10.1.15, 10.10.1.32, 10.10.1.45}”

webserver = “192.168.1.5”

dnsservers = “{ 208.67.222.222, 208.67.202.202 }”

pass in quick on $if_int proto tcp from $administradores to $ip_int port 22

pass out quick on $if_ext proto tcp from $administradores to $webserver port 80

pass out quick on $if_ext proto { tcp, udp } from any to $dnsservers port 53

PF: Filtragem de Pacotes – Conceitos básicos.

Apesar de um recursos poderoso e interessante não vamos abordar o funcionamento das tabelas, apenas citá-las  e dar a dica de que para listas muito grandes, é bem mais interessante o uso das mesmas. Procure no oráculo algo sobre elas, com certeza vai encontrar muito material escrito por pessoas que dominam bem seu uso.

As opções também são recursos importantes do PF, mas que não vamos usar para nosso “firewall básico”, o que não quer dizer que são dispensáveis. Conhecê-las e aplicá-las com certeza trará um controle muito maior sobre as aços do PF.

Vamos pular essas partes do arquivo de configuração e vamos tratar das regras de filtragem, com isso ficará mais fácil o entendimento das demais sessões, pois estaríamos falando de coisas sem saber sua aplicação.

A filtragem de pacotes nada mais é do que o bloqueio ou a liberação de pacotes de forma controlada. As regras de filtragem determinam o critério em que o pacote deve se enquadrar para ser submetido a uma determinada ação. As regras são analisadas em seqüência da primeira até a última, exceto no caso de um pacote casar com uma regra que contenha a palavra-chave quick, neste caso a regra será aplicada e o restante desconsiderado. Caso não haja a palavra quick, o pacote vai ser analisado por cada regra do arquivo de configuração, e vai ser casado com a última regra aonde ele se enquadre.

A forma simplificada da sintaxe de uma regra é:

ação [direção] [log] [quick] [on interface] [af] [proto protocolo] [from src_addr [port porta]] [to dst_addr [port porta]] [flags tcp_flags] [state]

Apesar de cansativo, vou tentar mostrar da forma mais simples possível o significado de cada uma delas:

• ação (pass ou block): é a ação que será executada caso o pacote case com a regra. Para o caso da ação ser block invocada, ela reagirá de acordo com a opção block-policy. Caso o block venha acompanhado de drop ou block a opção block-policy será ignorada, prevalencendo o drop ou block.
• direção (in ou out): é a direção do pacote na interface referenciada na regra. Naturalmente in se aplica aos pacotes que entram na interface, vindos de fora do servidor e out quando um pacote sai do servidor para a rede. 
• log: ordena que o pacote seja logado, caso este pacote implique na criação de um estado, somente o pacote que originou a criação será logado. Para compreender o log de pacotes, é importante você ler sobre pflogd (http://www.freebsd.org/cgi/man.cgi?query=pflogd&sektion=8)
• quick: Se o pacote casar com a regra que consta a palavra-chave quick a ação desta regra será aplicada e será também considerada a última regra a ser analisada para este pacote.
• Interface: nome ou grupo da interface de rede aonde o pacote vai ser analisado. Existem grupos padrões criados pelo sistema que enquadram as interfaces da rota padrão (egress) ou por exemplo as interfaces clonadas como ppp ou  carp. 
• af: define a família de endereços que o pacote pertence, sendo inet para IPV4 e inet6 para IPV6.
• protocolo: o protocolo de camada 4 do pacote (tcp, udp, icmp, icmp6). Podem ser referenciados por seu nome ou número (/etc/protocols), podem estar sozinhos ou na forma de uma lista. 
•  src_addr e dst_addr: Endereços de origem e destino que podem ser referenciados de várias formas: 
•  Endereço IPv4 (192.168.1.15) ou IPv6 simples (1080:0:0:0:8:800:200C:417A). 
•  Um bloco de rede CIDR. (http://public.pacbell.net/dedicated/cidr.html) 
•  Nome de domínio totalmente qualificado, que será resolvido pelo DNS quando as regras forem carregadas. 
•  O nome de uma interface de rede ou grupo. Quaisquer endereços IP na interface serão enquadrados na regra. 
• O nome de uma interface de rede seguido por uma /máscara (ex., /24). Cada endereço IP na interface é combinado com a máscara para formar um bloco de rede CIDR que se enquadrarão na regra. 
• O nome de uma interface de rede ou grupo entre parênteses ( ). Isto informa ao PF para atualizar a regra caso o endereço(os) da interface sofra alteração. Útil em interfaces que obtém seu endereço IP via DHCP ou dial-up, pois as outras regras não precisarão ser recarregadas toda vez que o endereço mudar. 
•  O nome de uma interface de rede seguido por algum dos modificadores:
• network - substitui o bloco de rede CIDR (ex., 192.168.0.0/24) 
• broadcast - substitui o endereço de broadcast (ex., 192.168.0.255) 
• peer - substitui o endereço da outra ponta num link ponto-a-ponto 
• Além disso, o modificador :0 pode ser adicionado a um nome de interface ou qualquer um dos modificadores acima para indicar ao PF para não incluir endereços IP de aliases na substituição. Estes modificadores também podem ser usados quando o nome da interface está entre parênteses. Exemplo: fxp0:network:0 
• Uma tabela.
• A palavra-chave urpf-failed pode ser usada para endereços de origem para indicar que devem passar pelo uRPF. 
• Qualquer dos apresentados acima, negado usando o modificador ! ("not") . 
• Um grupo de endereços usando-se uma lista. 
• A palavra-chave any indicando todos os endereços 
• A palavra-chave all que é um atalho para from any to any. 
• src_port e dst_port: A porta de origem/destino no cabeçalho da camada 4 do pacote que podem ser especificadas de várias formas: 
• Um número entre 1 e 65535 
• Nome de serviços válidos (/etc/services) 
• Uma lista 
• Uma faixa: 
• != Diferente 
• < Menor que 
• > Maior que 
• <= Menor ou igual a
• >= Maior ou igual a 
• >< Faixa
• <> Faixa inversa 
• : Faixa inclusiva
• tcp_flgs: Especifica que flags devem estar ligadas no cabeçalho TCP para que a regra case com o pacote. São especificadas na forma flags chek/mask, por default S/SA são aplicadas para todos os pacotes TCP. 
• state: Informa uma ação complementar para a regra no caso do pacote se enquadrar. Ordena que as informações de estado devem ser mantidas para este pacote. 
• keep state: funciona com TCP, UDP e ICMP – esta regra é padrão para todas as regras de filtragem.
• modulate state: funciona apenas com TCP, e fará com que o PF gere ISNs (Números de Seqüência Inicial) seguros para pacotes combinantes com a regra. 
• synproxy state:  faz proxy de pedidos de conexão TCP, basciamente para proteger o servidor de pacotes SYN TCP spoofados. Essa opção inclui keep state e modulate state.

PF: Arquivo básico comentado
Agora que já sabemos como o PF funciona em sua essência, podemos colocar a mão na massa e criarmos um arquivo básico de configuração do PF. Para ganharmos tempo, execute o comando: “wget http://suporte.ceart.udesc.br/bsd/pf01.txt -O /etc/pf.conf” (ou clique aqui) e em seguida, vamos analisa-lo.

fw# wget http://suporte.ceart.udesc.br/bsd/pf.txt -O /etc/pf.conf

fw# vim /etc/pf.conf

Eu costumo colocar muitos comentário no arquivo, mas para facilitar sua edição vamos comentar o aquivo aqui no tutorial, mas fica a dica de colocar sempre os comentários (precedidos por #) a cada linha, ficando mais fácil o entendimento depois.

A estrutura deste arquivo segue os pré requisitos do PF e também sugere uma forma de organização para os filtros. A lógica é a seguinte, para cada interface do servidor termos que tratar pacotes em 2 situações: quando entram (entrantes) e quando saem (de saída), então criaremos uma divisão nossa (só a título de organização) por interface e dentro delas por direção.

Para constar, tudo que segue o sinal de # neste arquivo é ignorado, por conseqüência não serve para nada além de comentar e organizar o arquivo.

As linhas de 1 a 9 são definições de macros, aonde atribuímos valores a variáveis, de tal forma que fique mais fácil ler o arquivo para mantê-lo e até mesmo para atualizá-lo. Deixem-me abrir um parênteses aqui para um exemplo. Neste caso mesmo, tenho utilizando a interface externa como sendo uma placa na minha rede internet, mas eventualmente estou em casa ou no trabalho, e os endereços IPs mudam, então basta eu alterar o endereço na linha da Macro, que todo o restante do arquivo já está funcionando corretamente.

Figura 53 - Macros no arquivo pf.conf

A linha 13 define o NAT da rede, ou seja, como os endereços internos serão traduzidos para a rede válida. No nosso caso, nossa rede interna é uma rede classe C (255.255.255.0), que vai de 10.10.1.1 até 10.10.1.255, sendo que o 255 é o último endereço da rede, e por conseqüência é o endereço de broadcast. Para saber mais sobre NAT, acesse http://pt.wikipedia.org/wiki/NAT, ou mesmo procure no oráculo ( google ) .

nat on $ifExt inet from $redeInt to any -> $ifExt

Outra grande discussão em relação a segurança e administração de redes é que "tipo" de política você vai usar. Existem três formas básicas de definir políticas de um firewall:

• Somente serviços especiais: É quando criamos um firewall para um ambiente específico (por exemplo um servidor WEB, um servidor de Arquivo, uma rádio on line, etc), ou seja, para proteger um equipamento ou conjunto de equipamentos que prestam serviços específicos. Neste caso o firewall será todo fechado e você abrirá somente os serviços necessários.
• Aberto por padrão: É quando todo o tráfego é liberado e as regras vão sendo criadas para controlar demandas indesejadas. Neste modelo de funcionamento o administrador deve atuar monitorando a rede, e ao descobrir comportamentos indesejados (como ataques, excesso de tráfego, tráfego indesejado, etc) cria regras impedindo as ações indesejadas. 
• Fechado por padrão: É quando todo tráfego no servidor é bloqueado e são criadas regras para liberar o que for permitido/desejado. Desta forma, o administrador da rede liberar os serviços a medida que haja demanda e estes não comprometam o funcionamento da rede.

A discussão sobre a eficácia de cada um deles é grande, mas na minha opinião tem acontecido de forma equivocada. Cada modelo deste apresentado é eficiente sim, mas dentro de um contexto. Então entendo que para cada necessidade uma solução se encaixa perfeitamente, e o que deve ser discutido é qual delas para demanda existente e não qual delas é melhor simplesmente por ser.

Eu tenho o entendimento de que para um gateway de uma rede grande, sem serviços internos críticos (como servidores de arquivos, banco de dados - intranets em geral) uma rede Aberta por Padrão é interessante, mas exige um monitoramente com mais cuidado para que não perca banda com ataques e ações indesejadas.

Já para redes institucionais de grande porte, com muitos usuários e serviços críticos defendo o uso de Firewalls Fechados por Padrão. No meu entender justificar isso é fácil, pois as implicações legais que recaem sobre a instituição em relação as ações dos usuários é bastante grande. Então, por exemplo, no caso de uma Universidade, com milhares de alunos, centenas de professores e técnicos além dos prestadores de serviço terceirizados e os usuários "em trânsito" (palestrantes, visitantes, alunos ouvintes, etc.) como manter o controle ou a monitoração com eficiência?

Vejam que neste ponto estou colocando uma opinião pessoal, então não vamos discutir se é certa ou errada, apenas usá-la como base para continuar o tutorial. Descubram por si só qual é a melhor realidade para seu ambiente, e boa sorte.

Na linha 15 colocamos uma regra bloqueando todo o tráfego. Lembrem-se que sem a palavra quick o PF segue o arquivo, se o pacote de dados se encaixar em alguma regra nas linhas que se seguirem, o que vai valer é a última regra.

block all

Vamos aproveitar um procedimento comum que é liberarmos todo o tráfego (de entrada e de saída) na Interface de loopback, para entendermos esse block no início do arquivo.  A linha 18 faz com que todo pacote que se referencie a interface lo0 seja liberado e as linhas abaixo não sejam analisadas.

pass quick on lo0 to any

Agora vamos tratar os pacotes que entram na interface externa, ou seja, tudo que vem da internet para o firewall. Neste arquivo inicial, vamos apenas tratar duas situações. A primeira (linha 21) é a liberação de alguns serviços ICMP, vindos de qualquer lugar para qualquer dos IPs carregados na placa de rede externa (no nosso caso apenas um). A outra (linha 22) é liberarmos o protocolo SSH (tcp na porta 22) para requisições vindas de qualquer computador da internet – é claro que futuramente vamos restringir isso (ou mesmo tirar essa possibilidade), limitando aos IPs que eventualmente o administrador vá usar. Em alguns casos é necessário que o continue assim, principalmente quando o Administrador não tiver como definir esses IPs. Existem várias formas de se proteger isso, desde VPN até uma segunda máquina como firewall para impedir uma primeira onda de ataques.

Para essa mesma interface, mas para os pacotes de saída, vamos criar apenas uma regra permitindo a saída de qualquer pacote. A lógica disso é a seguinte, para que um pacote mau intencionado saía do firewall ele tem que ter se originado a partir da própria console, o que asseguraria ao agente provocador tem o “poder” para alterar a configuração da máquina e desligar o firewall. Nada impede que você crie uma regra de saída para cada necessidade, mas não será essa nossa linha de ação.

pass out quick on $ifExt to any

Observem que tratamos os dois sentidos possíveis na interface externa, agora vamos tratar a interface interna, também dividindo em duas partes, os pacotes de entrada e de saída.

Vamos criar desde já uma regra para as consultas de DNS (linha 53), outra para liberação de PING (linha 29) e outra para Liberação de SSH (linha 31). No caso do SSH, vamos liberar requisições somente para a máquina do Administrador da rede. Claro que pode ser considerado liberar o SSH para toda a rede interna (afinal liberamos para toda rede externa), mas para fins didáticos (e para não entrar na discussão do que é melhor) vamos nos ater a liberar apenas para uma máquina.

pass in quick on $ifInt inet proto icmp from $redeInt to any icmp-type { echorep, echoreq, timex, unreach }
pass in quick on $ifInt proto { tcp,udp } to $ipInt port 53
pass in quick on $ifInt proto tcp from $admin to $ipInt port 22

Novamente temos uma regra liberando todo o tráfego originado no firewall para toda a rede interna – linha 30.

pass out quick on $ifInt to any

Com isso feito, já podemos conhecer o comando pfctl, que “controla” o PF, desde a verificação do arquivo até mesmo habilitar ou desabilitar regras e etc.

Habilitar o PF

fw# pfctl –e 

Desligar o PF

fw# pfctl –d 

Carrega o arquivo /etc/pf.conf

fw# pfctl –f /etc/pf.conf 

Analisa o arquivo /etc/pf.conf, mas não carrega as regras

fw# pfctl –nf /etc/pf.conf 

Carrega apenas as regras de NAT do arquivo /etc/pf.conf

fw# pfctl –Nf /etc/pf.conf 

Carrega apenas as regras de filtragem do arquivo /etc/pf.conf

fw# pfctl –Rf /etc/pf.conf 

Mostra as regras ativas de NAT

fw# pfctl –sn 

Mostra as regras ativas de filtragem

fw# pfctl –sr 

Mostra o status da filtragem e contadores

fw# pfctl –si

Mostra tudo (all) que pode ser mostrado

fw# pfctl –as 

Limpa todas as regras

fw# pfctl –F all 

Então vamos testar o arquivo, executando:

fw# pfctl –nf /etc/pf.conf

Devemos receber algo parecido com a tela abaixo como resposta:

fw# pfctl –nf /etc/pf.conf

no IP address found for me0

/etc/pf.conf:17: cold not parse host specification

Se ao editar o arquivo você se lembrou de corrigir as interfaces para as que você tem em seu ambiente esse erro não vai aparecer. Ele serve para duas coisas, a primeira é mostrar a função do comando para analisar o arquivo sem carregar as regras e a segunda é lembrar que o nome das interfaces não será o mesmo (a menos que você também esteja usando o VMWare Workstation para implementar esse servidor. No meu caso, basta editar o arquivo /etc/pf.conf e corrigir as linhas 2 e 3 trocando me0 e me1 para em0 e em1.

Quando executar o comando novamente, não receberá nenhuma mensagem, o que significa que o arquivo esta ok.

Para carregar as regras que criamos, basta executar:

fw# pfctl –f /etc/pf.conf

O Resultado deve ser:

fw# pfctl –f /etc/pf.conf

No ALTQ support in kernel

ALTQ related functions disabled

As mensagens sobre ALTQ informam que seu kernel não foi compilado com suporte ao controle de banda. Por hora, vamos deixar isso de lado, quem sabe alguém se anima a complementar esse tutorial com o QoS.

Nosso Firewall já está instalado, essa máquina já pode ser o gateway de sua rede, mas por enquanto, apenas como firewall. Para isso, vamos então fazer algumas alterações no arquivo pf.conf, para permitir consultas de dns a um servidor externo, e também a navegação através da porta 80.

Vamos criar uma nova macro, chamada servidorDns, para conter o IP do servidor DNS que vamos usar.

servidorDns = "208.67.222.222"

Na seqüência, vamos editar a regra que criamos liberando as consultas de DNS para o próprio servidor de tal forma que as consultas feitas para um servidor externo sejam permitidas.

pass in quick on $ifInt proto { tcp,udp } to $servidorDns port 53

A outra regra que temos que adicionar (pode ser logo após esta) é a liberação da porta 80 para qualquer endereço:

pass in quick on $ifInt proto tcp from $redeInt to any port 80

Após inserirmos essas duas linhas, executamos o comando abaixo para limparmos as regras existentes e em seguida recarregarmos as novas:

fw# pfctl –Fa && pfctl –f /etc/pf.conf

Como teste você deve colocar uma maquina ligada a Interface Interna aonde o gateway deve ser o IP da interface interna e o DNS o mesmo que você atribuiu a macro "servidorDNS". No meu caso, ficaria assim (usando uma maquina com Windows XP):

Endereço IP: 10.10.1.10

Máscara de sub-rede: 255.255.255.0

Gateway padrão: 10.10.1.1

Seridor DNS preferencial: 208.67.222.222

Seridor DNS alternativo: 208.67.220.220

Vejam que estou usando dois servidores DNS (o primário e o secundário), mas nossa regra no PF libera apenas o primeiro. Para corrigirmos isso, basta alterar a linha da macro de:

servidorDns = "208.67.222.222"

Para:

servidorDns = "{208.67.222.222,208.67.220.220}"

Desta forma, a regra que se aplica a macro "servidorDns" valerá para os dois IPs.

Está quase tudo pronto para testar o funcionamento, mas se você lembrar da Figura 23 deste tutorial, vai ver que não habilitamos nosso freeBSD para atuar como gateway, então, adicione a linha gateway_enable=”YES” e faça um reboot no BSD.

fw# echo gateway_enable=\"YES\" >> /etc/rc.conf

Pronto, já temos um gateway para nossa rede, com um firewall.


O próximo tutorial será da instalação do proxy SQUID neste mesmo ambiente.

Abraços.