A console gráfica do pFsense (na qual vocë pode operar todos os serviços do servidor), pode ser acessada através dos principais navegadores de Internet, em qualquer sistema operacional.

É uma grande vantagem, pois não cria praticamente nenhuma restrição para as máquinas dos administradores de rede que irão operá-la.

2. Sistema Operacional Dedicado

O pFsense é um Sistema Operacional (customização do FreeBSD), apenas com os pacotes essenciais para os serviços de Firewall, VPN… Por isso, consome menos recursos da CPU, além de possuir menos código.

Sabe-se, que quanto mais código (pacotes instalados), aumenta a quantidade de “bugs” no sistema e, dessa forma, possíveis vulnerabilidades de segurança.

3. Completamente Gerenciável pela Interface Gráfica (GUI)

Nem todos sentem familiariedade com o shell, VIM, etc. Por isso, a Interface Gráfica Web deixa mais amigável a tarefa de gerenciar (configurar) os serviços do pFsense.

4. Identificação dos Sistemas Operacionais

pfSense utiliza o p0f, uma avançada identificação de Sistema Operacional/network que permite filtrar no início da conexão. Quer que máquinas FreeBSD e Linux se conectem com a Internet, mas bloquear as Windows? pfSense pode fazê-lo (dentre outras possibilidadas) detectando passivamente o sistema operacional em uso.

5. Gráficos para Gerenciamento

O pfSense mantém informação em histórico das seguintes informações:

* Utilização da CPU
* “Throughput” total.
* Dados do Firewall
* “Throughputs” individualizados para cada interface.
* Razão de Pacotes por secundo em todas as interfaces
* Tempos de acesso do Gateway da Interface WAN

6. Cluster HA e HP

Capacidade nativa de configuração em cluster, com funcionalidade de balanceamento de carga e redundância para minimizar impactos de uma possível falha.

2. Não adicione uma regra se você não sabe o que está fazendo.

3. Adicione apenas as regras estritamente necessárias.

4. Faça backup de suas regras e configuração antes de qualquer mudança.

5. Documente tudo, o tempo todo.

6. Insira descrição nas suas regras (facilite a sua vida e a de seu sucessor!)

7. As regras devem ser inseridas sempre na interface de origem do pacote.

Olá, este artigo foi baseado no “Installing PfSense in a Vmware” do próprio site do desenvolvedor:

* http://www.pfsense.com/mirror.php?section=…vmware.html

Este artigo mostra como instalar o Pfsense, uma poderosa ferramenta de firewall baseada em FreeBSD com uma interface web amigável para criação de regras de firewall, proxy e inclusive Vlans no VMWare para que você possa testar a ferramenta.

Primeiro iremos precisar dos seguintes arquivos:

VMware Server 1.0.2
http://www.vmware.com/download/server/

Pfsense:
http://www.pfsense.com/mirror.php?section=downloads

Este artigo está utilizando a versão 1.0:

ftp://reflection.ncsa.uiuc.edu/…/pfSense-LiveCD-1.0-RELEASE-Installer.iso

Com todos os arquivos na mão e devidamente instalados, iremos começar a instalar!

Criando a máquina virtual

No VMware, vá em New > Virtual Machine:

Escolha Custom:

Na próxima tela escolha “Other” e selecione a opção “FreeBSD”.

Em “Virtual Machine Name” defina o nome da sua máquina, neste exemplo iremos chamar de “PfSense”.

A próxima tela irá perguntar se você quer definir esta máquina como uma máquina privativa, isso acontece somente em versões do Windows XP (não sei se acontece no Windows 2000).

Vamos em frente!

Agora iremos dizer ao VMware quem tem permissões para Start/Shutdown na máquina virtual, escolhi a “User that powers on the virtual machine”, que é o usuário logado na máquina no momento.

Você pode usar uma conta do sistema ou definir um usuário.

A próxima tela é sobre o processador, se você tem um ou dois (biprocessado), escolha a sua.

Agora ele pede para você definir a memória da máquina virtual, lembrando que, dependendo da memória da sua máquina, ambas podem ficar lentas, a minha tem 1gb, então dei 128mb pro pfsense (é só Shell mesmo :P).

Network Type. Iremos usar o modo Bridge mesmo (a primeira opção).

SCSI Adapter, escolheremos a opção BUS LOGIC.

Agora ele pede se você deseja criar um disco, usar um disco existente ou usar o próprio disco físico. Iremos criar um novo disco, então selecione “Create a New Virtual Disk”

Virtual Disk Type, escolha IDE.
Disk Size, defina o tamanho desse disco e clique em Next.
Disk File, defina o nome do Disco, eu coloquei pfsense.vmdk.

Clique em “Concluir”, pronto, temos a máquina virtual criada, agora iremos configurar outras opções.

Com tudo criado iremos clicar em “Edit this Virtual Machine”. Em ” Hardware” clique em “Add”.

Selecione “Ethernet Adapter”, clique em Next, selecione “Custom” e selecione VMNetX (onde X é o numero da placa).

Clique em “Concluir”.

Clique novamente em “Edit This Virtual Machine” selecione “CD-ROM” e vá em “Use ISO Image”

Selecione a imagem do PFSense

Eeee. Dê Start!!!

Instalando o PFSense

Irá aparecer a tela de instalação do FreeBSD, opsss, PfSense :D, selecione a opção 1: “Boot FreeBSD [Default]“.

Depois de aparecer um monte de linhas irá cair na opção “Do you Want the Setup VLans Now”, diga “N” e atente que ali em cima aparecem as duas placas de rede.

Ele irá pedir agora quais são as interfaces de rede que você possui, na primeira coloque conforme apareceu na imagem passada e também na segunda opção, no meu caso le0 e le1. Dê enter (2x).

Ele agora irá confirmar os dados de quem é Lan e quem é WAN, se você está certo disso diga “Y” e dê enter.

Ok, ele irá cair na tela inicial, como vamos instalar, escolha a opção 99 “Install Pfsense…”

Configure Console
Selecione “Accept these Settings”
Select Task “Install Pfsense”
Select a Disk

Ele irá mostrar o disco que o VMWare criou:

Format this Disk?

Sim, formate o disco!

Na próxima tela não mude nada, apenas selecione “Use this Geometry”. Agora ele pede para você confirmar se deseja realmente formatar o disco, diga “Sim, Eu aceito”. hehehehe

Como é comum em sistemas BSD, ele também terá que particionar o disco (SWAP), etc. Depois que você seleciona o disco ele irá te dizer que o disco não está particionado corretamente e se você deseja que ele particione para você, como uma boa ação você irá selecionar “Partition Disk”.

Ok, agora ele mostra que irá formatar o disco com sistema de arquivos “FreeBSD”, ATENÇÃO, não confunda Sistema de arquivos com ponto de montagem ok? Selecione “Accept e Create”.

Depois ele pede para você confirmar novamente, você confirma e dá Ok, no final ele mostrará o disco formatado.

Depois disso ele pede se você deseja instalar o BootBlock, diga “Sim, eu Aceito” = “Accept and Install BootBlocks”.

Ele pedirá as partições que você deseja instalar, como só temos uma vai nessa mesmo.

Agora ele pergunta se “Você está certo disso?”.

Pronto, nessa parte você pode definir os pontos de montagem, eu deixei default mesmo, mas você pode fazer como melhor achar.

Ele irá instalar o PFsense, no final ele pede para que você reboot, mas antes vá em VM > Settings selecione CD-ROM e marque novamente “Use a Phisycal Drive”.

Ele iniciará normalmente o sistema, agora iremos configurar as placas de rede.

Selecione a Opção “Shell”. E como no Linux faça:

# ifconfig le0 <IP> netmask <Máscara>
# ifconfig le1 <IP> netmask <Máscara>

Se tudo ocorrer certo, agora você vai no navegador da sua máquina e digita:

http://ip.do.pfsense

Abrirá a tela para autenticar, coloque:

User: admin
Senha: pfsense

Altere depois que se logar e, pronto, divirta-se!

Mais referências podem ser encontradas em:

• http://www.pfsense.com

Desculpem se não fui muito claro, qualquer coisa podem escrever nos comentários ou mandar um e-mail: augusto@slackbr.org.

Abraços.

fonte: http://www.vivaolinux.com.br/artigo/Instalando-o-PFSense-em-uma-maquina-virtual/

Ainda, estão listadas as limitações da ferramenta, que são comuns, inclusive, a muitos softwares proprietários.

Firewall

* Filtro por IP de origem e destino, protocolo IP, porta de origem e destino, para tráfego TCP e UDP.Filtering by source
* Habilidade de limitar conexões simultâneas.
* pfSense utiliza o p0f, uma avançada identificação de Sistema Operacional/network que permite filtrar no início da conexão. Quer que máquinas FreeBSD e Linux se conectem com a Internet, mas bloquear as Windows? pfSense pode fazê-lo (dentre outras possibilidadas) detectando passivamente o sistema operacional em uso.
* Option to log or not log traffic matching each rule.
* Highly flexible policy routing possible by selecting gateway on a per-rule basis (for load balancing, failover, multiple WAN, etc.)
* Aliases allow grouping and naming of IPs, networks and ports. This helps keep your firewall ruleset clean and easy to understand, especially in environments with multiple public IPs and numerous servers.
* Transparent layer 2 firewalling capable - can bridge interfaces and filter traffic between them, even allowing for an IP-less firewall (though you probably want an IP for management purposes).
* Packet normalization - Description from the pf scrub documentation - “‘Scrubbing’ is the normalization of packets so there are no ambiguities in interpretation by the ultimate destination of the packet. The scrub directive also reassembles fragmented packets, protecting some operating systems from some forms of attack, and drops TCP packets that have invalid flag combinations.”
o Enabled in pfSense by default
o Can disable if necessary. This option causes problems for some NFS implementations, but is safe and should be left enabled on most installations.
* Disable filter - you can turn off the firewall filter entirely if you wish to turn pfSense into a pure router.

State Table

The firewall’s state table maintains information on your open network connections. pfSense is a stateful firewall, by default all rules are stateful.

Most firewalls lack the ability to finely control your state table. pfSense has numerous features allowing granular control of your state table, thanks to the abilities of OpenBSD’s pf.

* Adjustable state table size - there are multiple production pfSense installations using several hundred thousand states. The default state table size is 10,000, but it can be increased on the fly to your desired size. Each state takes approximately 1 KB of RAM, so keep in mind memory usage when sizing your state table. Do not set it arbitrarily high.
* On a per-rule basis:
o Limit simultaneous client connections
o Limit states per host
o Limit new connections per second
o Define state timeout
o Define state type
* State types - pfSense offers multiple options for state handling.
o Keep state - Works with all protocols. Default for all rules.
o Modulate state - Works only with TCP. pfSense will generate strong Initial Sequence Numbers (ISNs) on behalf of the host.
o Synproxy state - Proxies incoming TCP connections to help protect servers from spoofed TCP SYN floods. This option includes the functionality of keep state and modulate state combined.
o None - Do not keep any state entries for this traffic. This is very rarely desirable, but is available because it can be useful under some limited circumstances.
* State table optimization options - pf offers four options for state table optimization.
o Normal - the default algorithm
o High latency - Useful for high latency links, such as satellite connections. Expires idle connections later than normal.
o Aggressive - Expires idle connections more quickly. More efficient use of hardware resources, but can drop legitimate connections.
o Conservative - Tries to avoid dropping legitimate connections at the expense of increased memory usage and CPU utilization.

Network Address Translation (NAT)

* Port forwards including ranges and the use of multiple public IPs
* 1:1 NAT for individual IPs or entire subnets.
* Outbound NAT
o Default settings NAT all outbound traffic to the WAN IP. In multiple WAN scenarios, the default settings NAT outbound traffic to the IP of the WAN interface being used.
o Advanced Outbound NAT allows this default behavior to be disabled, and enables the creation of very flexible NAT (or no NAT) rules.
* NAT Reflection - in some configurations, NAT reflection is possible so services can be accessed by public IP from internal networks.

NAT Limitations

* PPTP and GRE Limitation - The state tracking code in pf for the GRE protocol can only track a single session per public IP per external server. This means if you use PPTP VPN connections, only one internal machine can connect simultaneously to a PPTP server on the Internet. A thousand machines can connect simultaneously to a thousand different PPTP servers, but only one simultaneously to a single server. The only available work around is to use multiple public IPs on your firewall, one per client, or to use multiple public IPs on the external PPTP server. This is not a problem with other types of VPN connections. A solution for this is currently under development.
* SIP Limitation - By default, all TCP and UDP traffic other than SIP and IPsec gets the source port rewritten. More information on this can be found in the static port documentation. Because this source port rewriting is how pf tracks which internal IP made the connection to the given external server, and most all SIP traffic uses the same source port, only one SIP device can connect simultaneously to a single server on the Internet. Unless your SIP devices can operate with source port rewriting (most can’t), you cannot use multiple phones with a single outside server without using a dedicated public IP per device. The sipproxd package now provides a solution for this problem in pfSense 1.2.1 and newer.
* NAT Reflection limitations - NAT reflection can only be used with port ranges less than 500 ports and cannot be used with 1:1 NAT hosts.

Redundancy

CARP from OpenBSD allows for hardware failover. Two or more firewalls can be configured as a failover group. If one interface fails on the primary or the primary goes offline entirely, the secondary becomes active. pfSense also includes configuration synchronization capabilities, so you make your configuration changes on the primary and they automatically synchronize to the secondary firewall.

pfsync ensures the firewall’s state table is replicated to all failover configured firewalls. This means your existing connections will be maintained in the case of failure, which is important to prevent network disruptions.
Limitations

* Only works with static public IPs, does not work with DHCP, PPPoE, PPTP, or BigPond type WANs (will be resolved in a future release)
* Requires a minimum of three public IP addresses (will be resolved in a future release)
* Backup firewalls are idle (active-passive failover), no active-active clustering is possible at this time.
* Failover is not instantaneous, it takes about 5 seconds to switch a backup host to master. During this time no traffic will be passed, but existing states will maintain connectivity after failover is completed. This 5 second outage during a failure isn’t even noticeable in most environments.

Load Balancing
Outbound Load Balancing

Outbound load balancing is used with multiple WAN connections to provide load balancing and failover capabilities. Traffic is directed to the desired gateway or load balancing pool on a per-firewall rule basis.
Inbound Load Balancing

Inbound load balancing is used to distribute load between multiple servers. This is commonly used with web servers, mail servers, and others. Servers that fail to respond to ping requests or TCP port connections are removed from the pool.
Limitations

* Equally distributes load between all available servers - unable to unequally distribute load between servers at this time.
* Only checks if the server responds to pings or TCP port connections. Cannot check if the server is returning valid content.

VPN

pfSense offers three options for VPN connectivity, IPsec, OpenVPN, and PPTP.
IPsec

IPsec allows connectivity with any device supporting standard IPsec. This is most commonly used for site to site connectivity to other pfSense installations, other open source firewalls (m0n0wall, etc.), and most all commercial firewall solutions (Cisco, Juniper, etc.). It can also be used for mobile client connectivity.
Limitations

* NAT-T is not supported, which means mobile clients behind NAT are not supported. This limits pfSense’s usefulness with mobile IPsec clients. OpenVPN or PPTP is a better solution.
* Only one end of an IPsec tunnel can have a dynamic IP address.
* Some of the more advanced capabilities of ipsec-tools are not yet supported, including DPD, XAuth, NAT-T, and others.

OpenVPN

OpenVPN is a flexible, powerful SSL VPN solution supporting a wide range of client operating systems. See the OpenVPN website for details on its abilities.
Limitations

* Not all of the capabilities of OpenVPN are supported yet. Support for virtually all of OpenVPN’s capabilities will be included in the next release.
* Filtering of OpenVPN traffic is not yet possible. Support for this will be in the next release.

PPTP Server

PPTP is a popular VPN option because nearly every OS has a built in PPTP client, including every Windows release since Windows 95 OSR2. See this Wikipedia article for more information on the PPTP protocol.

The pfSense PPTP Server can use a local user database, or a RADIUS server for authentication. RADIUS accounting is also supported. Firewall rules on the PPTP interface control traffic initiated by PPTP clients.
Limitations

* Because of limitations in pf NAT, when the PPTP Server is enabled, PPTP clients cannot use the same public IP for outbound PPTP connections. This means if you have only one public IP, and use the PPTP Server, PPTP clients inside your network will not work. The work around is to use a second public IP with Advanced Outbound NAT for your internal clients. See also the PPTP limitation under NAT on this page.

PPPoE Server

pfSense offers a PPPoE server. For more information on the PPPoE protocol, see this Wikipedia entry. A local user database can be used for authentication, and RADIUS authentication with optional accounting is also supported.
Reporting and Monitoring
RRD Graphs

The RRD graphs in pfSense maintain historical information on the following.

* CPU utilization
* Total throughput
* Firewall states
* Individual throughput for all interfaces
* Packets per second rates for all interfaces
* WAN interface gateway(s) ping response times
* Traffic shaper queues on systems with traffic shaping enable

Real Time Information

Historical information is important, but sometimes it’s more important to see real time information.

SVG graphs are available that show real time throughput for each interface.

For traffic shaper users, the Status -> Queues screen provides a real time display of queue usage using AJAX updated gauges.

The front page includes AJAX gauges for display of real time CPU, memory, swap and disk usage, and state table size.
Dynamic DNS

A Dynamic DNS client is included to allow you to register your public IP with a number of dynamic DNS service providers.

* DynDNS
* DHS
* DyNS
* easyDNS
* No-IP
* ODS.org
* ZoneEdit

A client is also available for RFC 2136 dynamic DNS updates, for use with DNS servers like BIND which support this means of updating.
Limitations

* Only works on primary WAN interface - multi-WAN support not available at this time.
* Can only update one account with a single provider.
* Only works when pfSense has the public IP assigned to one of its interfaces. If you have a modem that obtains your public IP and gives pfSense a private IP, the private IP will be registered with the provider.

Captive Portal

Captive portal allows you to force authentication, or redirection to a click through page for network access. This is commonly used on hot spot networks, but is also widely used in corporate networks for an additional layer of security on wireless or Internet access. For more information on captive portal technology in general, see the Wikipedia article on the topic. The following is a list of features in the pfSense Captive Portal.

* Maximum concurrent connections - Limit the number of connections to the portal itself per client IP. This feature prevents a denial of service from client PCs sending network traffic repeatedly without authenticating or clicking through the splash page.
* Idle timeout - Disconnect clients who are idle for more than the defined number of minutes.
* Hard timeout - Force a disconnect of all clients after the defined number of minutes.
* Logon pop up window - Option to pop up a window with a log off button.
* URL Redirection - after authenticating or clicking through the captive portal, users can be forcefully redirected to the defined URL.
* MAC filtering - by default, pfSense filters using MAC addresses. If you have a subnet behind a router on a captive portal enabled interface, every machine behind the router will be authorized after one user is authorized. MAC filtering can be disabled for these scenarios.
* Authentication options - There are three authentication options available.
o No authentication - This means the user just clicks through your portal page without entering credentials.
o Local user manager - A local user database can be configured and used for authentication.
o RADIUS authentication - This is the preferred authentication method for corporate environments and ISPs. It can be used to authenticate from Microsoft Active Directory and numerous other RADIUS servers.
* RADIUS capabilities
o Forced re-authentication
o Able to send Accounting updates
o RADIUS MAC authentication allows captive portal to authenticate to a RADIUS server using the client’s MAC address as the user name and password.
o Allows configuration of redundant RADIUS servers.
* HTTP or HTTPS - The portal page can be configured to use either HTTP or HTTPS.
* Pass-through MAC and IP addresses - MAC and IP addresses can be white listed to bypass the portal. Any machines with NAT port forwards will need to be bypassed so the reply traffic does not hit the portal. You may wish to exclude some machines for other reasons.
* File Manager - This allows you to upload images for use in your portal pages.

Limitations

* Can only run on one interface simultaneously.
* “Reverse” portal, i.e. capturing traffic originating from the Internet and entering your network, is not possible.
* Only entire IP and MAC addresses can be excluded from the portal, not individual protocols and ports.
* Currently not compatible with multi-WAN rules (will be fixed in the next release)

DHCP Server and Relay

pfSense includes both DHCP Server and Relay functionality

“O IPFIREWALL é o filtro de pacotes nativo do FreeBSD, sendo também chamado de IPFW, que é a interface para controle do IPFIREWALL. O IPFIREWALL faz o monitoramento de cada pacote em cada conexão feita à máquina, determinando por meio das regras definidas pelo IPFW qual é o tratamento dado a estes pacotes. As regras são lidas de cima para baixo, e podem determinar se o pacote será liberado, bloqueado, encaminhado etc.

Atualmente podemos ativar o suporte a IPFW2. O IPFW2 é uma nova versão do IPFW, com maior flexibilidade no formato das regras e algumas funcionalidades a mais, entre elas: suporte a regras não específicas para TCP ou UDP com número de porta, suporte a blocos OR, keepalives para sessões stateful e filtragem por cabeçalho MAC.
Ativando o IPFW2

Para habilitar o suporte ao ipfirewall e o ipfw2, devemos seguir alguns passos. Inicialmente, o próprio ipfw deverá ser recompilado, para suportar ipfw2. Execute os seguintes comandos:

# cd /usr/src/sbin/ipfw
# make clean
# make -DIPFW2
# make -DIPFW2 install

Para que quando formos atualizar o sistema e executar um “make buildworld” o make saiba deste detalhe no momento de compilar o ipfw, adicione a linha abaixo ao arquivo /etc/make.conf:

IPFW2=TRUE

Edite o arquivo de configuração do kernel e insira as seguintes linhas, descritas abaixo:

options IPFIREWALL
options IPFW2
options IPFIREWALL_VERBOSE
options IPFIREWALL_VERBOSE_LIMIT=100
options IPFIREWALL_FORWARD
options IPDIVERT

Primeira linha: ativa o ipfirewall, carregando-o estaticamente no kernel.
Segunda linha: ativa o ipfw2 propriamente dito.
Terceira linha: ativa o suporte a log no ipfirewall. O log é feito via syslog.
Quarta linha: define um limite para o log de cada regra. O padrão é 100, dessa forma cada regra terá até 100 ocorrências no log. Isto é feito para evitar o comprometimento do sistema em caso de ataques como negação de serviço.
Quarta linha: ativa o suporte a encaminhamento de pacotes.
Quinta linha: ativa o suporte a redirecionamento de porta através de socket “divert”.

Após todas estas configurações, compile e reinstale o kernel, e reinicie a máquina. Isto deverá ser feito no console, pois após reiniciar o firewall será carregado, e como não foi definida nenhuma regra irá bloquear tudo. Uma forma de contornar isso, caso não seja possível estar junto a máquina, é inserir as seguintes linhas no arquivo /etc/rc.conf:

firewall_enable=”YES”
firewall_type=”OPEN”

Isto fará com que na inicialização seja carregada a configuração “OPEN” do arquivo /etc/rc.firewall. Esta configuração irá adicionar uma regra que libera todo o tráfego.

Após reiniciada a máquina, digite o seguinte comando:

# ipfw list

Será mostrada a lista de regras ativas, que de acordo com a configuração OPEN do arquivo /etc/rc.firewall deverá ser a seguinte:

00100 allow ip from any to any via lo0
00200 deny ip from any to 127.0.0.0/8
00300 deny ip from 127.0.0.0/8 to any
65000 allow ip from any to any
65535 deny ip from any to any

Neste momento, todos os pacotes que entram e saem da máquina estão passando por estas regras, na ordem em que estão, definida pelo número da regra (que vai de 1 a 65535). A primeira regra que for atendida irá definir o que fazer com o pacote, e as demais são geralmente ignoradas (em alguns casos específicos o pacote é reinjetado).

Regra 100: permite que qualquer pacote IP trafegue na interface lo0 (localhost).
Regra 200: bloqueia o tráfego de qualquer origem para a rede 127.0.0.0/8 (localhost).
Regra 300: bloqueia o tráfego com origem na rede 127.0.0.0/8 para qualquer destino.
Regra 65000: permite qualquer tráfego.
Regra 65535: bloqueia qualquer tráfego.

Estas regras estão no formato do ipfw1, que também é suportado, para compatibilidade, pelo ipfw2. Lembre-se que todas estas regras foram definidas pelo rc.firewall, exceto a regra de número 65535 (máximo), que é o padrão do ipfirewall, bloquear tudo. Caso seja conveniente que o padrão do firewall seja liberar tudo, ou seja, a regra 65535 seria “allow all from any to any”, então deve ser adicionada a seguinte linha na configuração do kernel:

options IPFIREWALL_DEFAULT_TO_ACCEPT

Comando IPFW

O comando ipfw, de uma forma sucinta, possui os seguintes parâmetros:

ipfw [-q] add regra -> Adiciona a regra (ver o formato abaixo). A opção “-q” indica que deverá ser uma operação “silenciosa”, não gerando saídas nem relatando as ações.

ipfw delete número_regra -> Remove a regra com o número especificado.

ipfw list -> Lista as regras ativas.

ipfw [-t -d] show -> Lista as regras ativas, incluindo os contadores número de pacotes e número de bytes. O parâmetro -t inclui ainda a data/hora da última ocorrência. O parâmetro -d lista também as regras dinâmicas.

ipfw [-q] flush -> Deleta todas as regras.

ipfw [-q] zero -> Zera todos os contadores (número de pacotes, número de bytes, número de logs e timestamp).

ipfw [-q] resetlog -> Zera o contador número de logs.

Formato das Regras

As regras que vimos anteriormente, como foi mencionado, estão no formato do ipfw1, que atualmente também é aceito pelo ipfw2. Pode-se usar este formato para escrever as regras, no entanto é bom se habituar com o novo formato. Quando forem acrescentadas regras no formato novo, o ipfw2 irá automaticamente inserir as palavras “ip from any to any”, que fazem parte do formato antigo, e não irão mudar em nada a regra, já que não impões nenhuma restrição, e quem vai ditar a especificação dos pacotes são as opções, explicadas adiante. Este esquema é feito para manter uma certa compatibilidade com o ipfw1.

A partir de agora, já podem ser definidas regras para controlar o Firewall. É muito importante se familiarizar com a sintaxe e forma de uso do ipfw, que será o único comando utilizado para controlar o ipfirewall. A formato das regras é o seguinte:

[número_regra] [prob probalilidade] ação [log [logamount número] ] corpo_regra

[número_regra]
Varia de 1 a 65535 e indica a seqüência em que as regras serão processadas. A número 65535 é reservado para a ação padrão do firewall, que será bloquear ou permitir tudo, dependendo da configuração do kernel. Se não for inserido um número de regra ela será automaticamente a última antes da 65535. Se forem inseridas duas ou mais regras com o mesmo número, será obedecida a ordem em que foram inseridas.

[prob probabilidade]
Define uma probabilidade para aplicar a regra. Varia de 0 a 1.

ação

allow
Sinônimo de accept, pass e permit. Libera o tráfego do pacote e termina a leitura das regras.

check-state
Checa o pacote contra um conjunto de regras dinâmico.

count
Apenas atualiza o contador desta regra. As demais regras continuam a ser lidas.

deny
Sinônimo de drop, descarta o pacote e termina a leitura das regras.

divert porta
Redireciona o pacote para a porta especificada, utilizando um socket “divert”. Pode ser especificado número ou nome, veja /etc/services.

fwd ip[,porta]
Sinônimo de forward, encaminha o pacote para o ip especificado. Se o ip for local será encaminhado para a porta especificada, se o ip não for local a porta será ignorada. O pacote não é alterado, e isto inclui o ip de destino, então se o pacote for encaminhado para outro host provavelmente será rejeitado. Caso seja encaminhado para um ip local, desta máquina, o socket que irá receber o pacote terá o seu endereço alterado para coincidir com o endereço de destino do pacote, aceitando desta forma o mesmo.

pipe número
Passa o pacote através de um “pipe” dummynet, para controle de tráfego.

queue número
Passa o pacote para uma “queue” dummynet, para controle de tráfego utilizando WF2Q+.

reset
Descarta o pacote, e se o mesmo for TCP tenta enviar um TCP RST.

skipto número
Pula para a regra de número especificado.

tee porta
Aceita o pacote e envia uma cópia do mesmo para a porta especificada, via socket “divert”.

unreach código
Descarta o pacote, e tenta enviar uma resposta “ICMP unreachable” com o código especificado. O código deve ser entre 0 e 255, ou alguma destas palavras chave: net, host, protocol, port, needfrag, srcfail, net-unknown, host-unknown, isolated, net-prohib, host-prohib, tosnet, toshost, filter-prohib, host-precedence ou precedence-cutoff.

[log [logamount número] ]
Caso mencionada a palavra log, cada vez que um pacote coincidir com esta regra será feito um log, através do syslog. Caso seja inserido logamount número, este será o limite de vezes que será feito o log para esta regra. O valor 0 (zero) significa sem limites. Caso não seja inserido logamount, o padrão é o limite que foi configurado no kernel.

corpo_regra
Contém uma ou mais exigências que o pacote precisa coincidir para a regra ser atendida. Essa especificação pode incluir endereço ip de origem, endereço ip de destino, porta de origem, porta de destino, protocolo, interface de rede de entrada, interface de rede de saída etc. O corpo da regra pode possuir uma ou mais opções. Essas opções podem ser precedidas de “not”, como negação, ou serem agrupadas em blocos OR, entre chaves, por exemplo: { dst-port 50 or dst-port 51 or not src-port 52 }.

A seguir as opções mais importantes:

// comentário
Insere o texto como sendo um comentário na regra.

dst-ip endereço
Endereço IP de destino do pacote.

dst-port porta
Porta(s) de destino do pacote. Se for especificada mais de uma porta, separar por vírgula (50, 51, 52), ou em faixa de portas (50-60).

established
Se o pacote tiver os bits RST ou ACK.

frag
fragmentos de pacotes, não sendo o primeiro fragmento.

gid grupo
Pacotes TCP ou UDP enviados ou recebidos pelo grupo. O grupo pode ser especificado pelo nome ou pelo GID.

icmptypes tipo
Tipo(s) de pacotes ICMP. Se for mais de um, separar por vírgula. Os tipos podem ser: echo reply (0), destination unreachable (3), source quench (4), redirect (5), echo request (8), router advertisement (9), router solicitation (10), time-to-live exceeded (11), IP header bad (12), timestamp request (13), timestamp reply (14), information request (15), information reply (16), address mask request (17) e address mask reply (18).

in | out
Pacotes de entrada ou de saída. Note que isto significa que os pacotes estão entrando ou saindo da máquina, então mesmo que um pacote venha da rede interna, estará entrando na máquina antes de sair.

keep-state
Quando um pacote coincidir com uma regra que tiver esta opção, será criada uma regra dinâmica, cujo comportamento será coincidir o tráfego bidirecional entre este ip/porta de origem e ip/porta de destino, no mesmo protocolo. A regra dinâmica expira após um certo tempo. Dessa forma, pode-se definir uma regra “check-state” anterior a esta, liberando este fluxo de pacotes, e teremos um firewall “stateful”.

limit {ip-origem | porta-origem | ip-destino | porta-destino} número
Serão permitidas apenas o número especificado de conexões com os parâmetros especificados.

mac mac-destino mac-origem
Pacotes com o endereço MAC de destino e/ou de origem especificados. Se não for especificado algum deverá ser usada a palavra “any”, para coincidir com todos os endereços.

proto protocolo
Pacotes com o protocolo (IP) especificado. Veja /etc/protocols.

recv interface | xmit interface | via interface
Pacotes recebidos pela interface de rede especificada (recv xl0), pacotes transmitidos pela interface especificada (xmit fxp0), ou pacotes passando pela interface, independentemente de entrar ou sair (via xl0). Quando xmit for utilizado é requerida a opção “out”, já que o pacote estará saindo.

setup
Pacotes com o bit SYN mas sem o bit ACK.

src-ip endereço
Endereço IP de origem do pacote.

src-port porta
Porta(s) de origem do pacote.

tcpflags flags
Flags dos pacotes TCP, separadas por vírgula. As possíveis são: fin, syn, rst, psh, ack e urg. A negação pode ser feita por um “!”.

uid usuário
Pacotes TCP ou UDP enviados ou recebidos pelo usuário. O usuário pode ser especificado pelo username ou pelo UID.

vrrevpath
Pra pacotes de entrada, é feita uma consulta ao endereço de origem na tabela de roteamento. Se a interface na qual o pacote entrou é a mesma de saída especificada pela rota, então a regra coincide. Isto pode ser utilizado para criar regras anti-spoofing. Os pacotes de saída não são submetidos à verificação.

Firewall Stateful

O funcionamento stateful permite que o firewall crie regras dinâmicas para fluxos específicos de pacotes. Pode-se fazer algumas coisas interessantes, como por exemplo manter o firewall fechado, bloqueando todo tráfego de fora para dentro e permitindo apenas que pacotes da rede interna saiam para a rede externa, passando por uma regra “keep-state”. Assim, cada conexão feita de dentro para fora irá criar uma regra dinâmica, que irá liberar aquele tráfego nas duas direções, permitindo que os dados de resposta, por exemplo, uma página web que um usuário acessou, cheguem até a máquina do usuário, na rede interna.
As regras dinâmicas possuem as seguintes informações: protocolo, endereço IP e porta de origem e endereço IP e porta de destino. Elas irão permitir o tráfego bidirecional, ou seja, mesmo que os endereços de origem e destino se invertam. Isto é uma das coisas que possibilita criar o que foi descrito acima. As regras dinâmicas possuem um tempo de vida limitado, que é determinado pelas variáveis net.inet.ip.fw.dyn*, do sysctl (maiores informações vide a man page do sysctl). Estas variáveis também determinam o número máximo de regras dinâmicas, entre outros.
Uma regra dinâmica é criada cada vez que um pacote coincide com uma regra que possua as opções keep-state ou limit, não sem antes checar se a regra já existe. As regras dinâmicas são checadas na ocorrência da ação check-state.

Exemplo:

# ipfw add 1000 check-state
# ipfw add 1100 allow tcp from 10.10.0.0/16 to any setup keep-state
# ipfw add 1200 deny tcp from any to any

Este conjunto de regras irá, para cada pacote:
1. Checar se existe alguma regra dinâmica que permita o tráfego do mesmo;
2. Caso o pacote seja da rede 10.10.0.0/16 e tiver o bit SYN, mas não o bit ACK (indicando desta forma um início de conexão), irá permitir o tráfego e criar uma regra dinâmica;
3. Bloquear qualquer outro tráfego.

Log

Para direcionar os logs do ipfw para o arquivo /var/log/ipfw/ipfw.log, primeiramente crie este diretório e este arquivo:

# mkdir /var/log/ipfw
# touch /var/log/ipfw/ipfw.log
# chmod -R 600 /var/log/ipfw

Então adicione as seguintes linhas ao arquivo /var/log/syslog.conf:

!ipfw
*.* /var/log/ipfw/ipfw.log

Após isso, reinicie o syslog, através do comando “killall -HUP syslog”. Talvez seja interessante também criar um script que faça a rotação deste log e agendar no Cron, ou adicionar uma entrada no newsyslog.conf, para que o arquivo não fique demasiado grande.

Arquivo de Regras

Não é recomendado editar o arquivo /etc/rc.firewall, que vem com o sistema. O seu conjunto de regras deverá ficar em um arquivo separado, exclusivo para isso. Este arquivo poderá ser um script shell ou poderá ser apenas uma listagem de regras, que o ipfw irá interpretar. O tipo de arquivo é uma escolha pessoal, e não fará diferença no funcionamento do firewall.

Arquivo com listagem de regras

Deverá ser criado um arquivo, por exemplo /etc/firewall, com dono root e permissão 600. Neste arquivo serão colocadas as regras, que são iguais às passadas via linha de comando ao ipfw, mas sem o comando “ipfw” no começo. Exemplo:

add 1000 allow src-ip 10.10.0.0/16 dst-ip 192.168.0.0/16

Para efetuar a inicialização destas regras no momento da inicialização, adicione ou modifique as seguintes linhas no /etc/rc.conf:

firewall_enable=”YES”
firewall_type=”/etc/firewall”
firewall_quiet=”YES”

A opção firewall_quiet faz com que seja executado o comando “ipfw -q” ao invés de simplesmente “ipfw”, ao ler cada regra do arquivo. Dessa forma ocorrerá uma operação “silenciosa”, não gerando saídas na tela. Para interpretar um arquivo deste tipo via linha de comando, simplesmente execute “ipfw /etc/firewall”.

Script de regras

No caso de criamos um script shell com as regras, também deverá ser criado um arquivo exclusivo para isso, como por exemplo /etc/firewall.sh, com dono root e permissão 700. O conteúdo deste arquivo pode ser como você quiser, pois trata-se de um script comum. Quando for passar as regras, o comando ipfw deve ser exatamente como se fosse via linha de comando. É recomendado usar a opção “-q”, do comando ipfw, em scripts.
Para que o script seja executado na inicialização do sistema, edite o arquivo /etc/rc.conf, remova as linhas (caso existirem) firewall_type e firewall_quiet, mantenha a linha

firewall_enable=”YES”

e adicione a seguinte linha:

firewall_script=”/etc/firewall.sh”

Deste ponto em diante, cabe a você decidir como deverá ser o comportamento do seu firewall, tendo em vista a que ele se destina. Sugiro a leitura do livro “Building Internet Firewalls”, de D. Brent Chapman e Elizabeth D. Zwicky, da editora O’Reilly. Seguem abaixo algumas regras e um script simples, a título de exemplo.

Exemplos de Regras

(não esquecer do comando “ipfw” antes delas):

add 100 allow via lo0
add 200 deny { dst-ip 127.0.0.0/8 or src-ip 127.0.0.0/8 }

Observe os espaços após a “{” e antes da “}”. Se não houver este espaço será retornado o seguinte erro:

ipfw in free(): warning: modified (chunk-) pointer

Estas duas regras acima terão o mesmo efeito que as regras abaixo, no formato antigo, descritas anteriormente:

add 100 pass all from any to any via lo0
add 200 deny all from any to 127.0.0.0/8
add 300 deny ip from 127.0.0.0/8 to any

add 1000 allow src-ip 10.10.0.0/16 dst-port 80
add 1100 allow dst-ip 10.10.0.0/16 dst-port 1024-65535

Irá permitir que máquinas da rede 10.10.0.0/16 enviem pacotes com destino a porta 80 e irá permitir que pacotes cheguem até a rede 10.10.0.0/16 com destino a portas entre 1024 e 65535, permitindo por exemplo a resposta de um pedido HTTP.

add 1000 allow proto tcp dst-port ssh recv xl0
add 1100 deny proto tcp dst-port ssh out

Irá permitir que a máquina receba conexões TCP pela interface de rede xl0, à porta do ssh, que é a porta 22, conforme definido no arquivo /etc/services. Também irá negar a saída de qualquer pacote com protocolo TCP e com destino a porta do ssh.

add 1000 check-state
add 1100 allow src-ip 10.10.0.0/16 keep-state
add 1200 deny log ip from any to any

Irá permitir que a rede 10.10.0.0/16 estabeleça qualquer conexão, cujo tráfego de resposta será liberado pelas regras dinâmicas que serão criadas pela regra 1100 e que serão checadas pela regra 1000. Qualquer outro tráfego será bloqueado e logado no arquivo de log.

add 50 deny not vrrevpath in

Irá bloquear ip-spoofing, conforme explicado anteriormente.

add 500 deny log { src-ip 10.0.0.0/8 or dst-ip 10.0.0.0/8 } via xl0
add 510 deny log { src-ip 172.16.0.0/12 or dst-ip 172.16.0.0/12 } via xl0
add 520 deny log { src-ip 192.168.0.0/16 or dst-ip 192.168.0.0/16 } via xl0

Irá proibir o tráfego de pacotes de redes privadas, conforme definido na RFC1918, na interface de rede xl0. Também irá fazer log quando a regra coincidir com algum pacote.

add 100 prob 0.05 deny in

Irá bloquear 5% dos pacotes de entrada, como se houvesse perda de pacotes.

Exemplo de Script

#!/bin/sh

ipfw=”/sbin/ipfw -q”

# IP local
ip=”10.10.0.5″

# Portas de entrada permitidas
portas=”22,53,80″

$ipfw flush
$ipfw add 100 deny log not verrevpath in
$ipfw add 1000 check-state
$ipfw add 1100 allow src-ip $ip keep-state
$ipfw add 1200 allow dst-port $portas in
$ipfw add 65000 deny ip from any to any”

Fonte: http://clebeer.multiply.com/journal/item/11/FreeBSD_com_IPFW