Aula 20: FreeBSD em produção — servidores corporativos, pfSense e OPNsense - BLOG

Bem-vindo à aula final do curso FreeBSD — Do Zero ao Avançado. Depois de dezenove aulas explorando instalação, gerenciamento de pacotes, ZFS, jails, rede, serviços e segurança, chegou o momento de consolidar todo esse conhecimento no ambiente mais crítico de qualquer infraestrutura: a produção. FreeBSD em produção não é apenas um chavão; é a realidade de milhares de empresas que dependem da previsibilidade, estabilidade e segurança desse sistema operacional para sustentar desde servidores web de alta disponibilidade até appliances de firewall que protegem redes inteiras. Nesta aula, você aprenderá a planejar, configurar e operar servidores corporativos FreeBSD, além de implementar e gerenciar dois dos firewalls mais respeitados do mercado — pfSense e OPNsense — ambos derivados diretamente do FreeBSD e do seu poderoso filtro de pacotes pf. Ao final, você terá executado procedimentos reais, verificado cada etapa e estará apto a defender com argumentos técnicos o uso do FreeBSD em qualquer mesa de decisão. Em nossos projetos na JRT Technology Solutions, nossos especialistas utilizam diariamente as práticas que você verá a seguir para manter ambientes críticos funcionando sem surpresas.

O que separa um servidor de laboratório de um servidor corporativo é a disciplina operacional. Não basta instalar o sistema e rodar um serviço: é preciso pensar em atualização contínua, monitoramento, redundância, recuperação de desastres e documentação. Nesta aula, vamos começar preparando um FreeBSD limpo para receber cargas de trabalho reais, passando pela configuração de serviços essenciais como Nginx e PostgreSQL, endurecendo o kernel e o firewall pf, criando jails para isolamento, e então integrando tudo com pfSense e OPNsense. Cada comando será mostrado em sua forma completa, com a saída esperada logo em seguida, para que você possa comparar com o seu próprio terminal e saber exatamente o que deve acontecer.

Os pré-requisitos para esta aula são o domínio dos conceitos das aulas anteriores: instalação do FreeBSD, manipulação de pacotes com pkg, noções de ZFS, jails, rede com ifconfig e edição de arquivos de configuração. Se você seguiu o curso até aqui, está pronto. Caso algum conceito ainda soe estranho, recomendamos revisitar a aula correspondente antes de prosseguir, pois aqui faremos uso intensivo de tudo o que foi apresentado. O ambiente mínimo sugerido é um servidor físico ou máquina virtual com FreeBSD 14.0-RELEASE ou superior, duas interfaces de rede e pelo menos 4 GB de RAM, embora para testes em laboratório 2 GB sejam suficientes.

Ao final desta aula, você será capaz de: preparar um FreeBSD para produção com tuning de kernel e hardening básico; configurar o firewall pf com regras específicas para serviços; instalar e configurar Nginx e PostgreSQL dentro de jails; implementar um appliance pfSense e um OPNsense do zero, compreendendo a relação direta deles com o FreeBSD; verificar a integridade e o funcionamento de cada componente; e diagnosticar os erros mais comuns com soluções completas. Esta é uma aula densa, pensada para ser executada na prática, não apenas lida. Prepare seu ambiente, faça um backup e vamos começar.

O que você vai aprender nesta aula

Preparar o FreeBSD para uso corporativo, incluindo tuning de sysctl, limites de recursos e boas práticas de segurança.
Configurar o firewall pf diretamente no FreeBSD, entendendo sua sintaxe e aplicação em servidores de produção.
Instalar e configurar Nginx e PostgreSQL em ambiente isolado com jails, simulando uma arquitetura de serviços segregados.
Compreender a relação entre FreeBSD, pfSense e OPNsense e por que esses firewalls dominam o mercado de appliances de borda.
Implantar um pfSense do zero, configurando interfaces, regras de firewall e serviços básicos de rede.
Implantar um OPNsense, integrá-lo com servidores FreeBSD via syslog e monitoramento, e validar a comunicação.
Executar todas as verificações de funcionamento com comandos reais e saídas esperadas.
Identificar e corrigir os erros mais frequentes em ambientes FreeBSD em produção.
Revisar as melhores práticas e encerrar o curso com um panorama completo do ecossistema FreeBSD.

Pré-requisitos e Ambiente

Para executar todos os procedimentos desta aula, você precisa de um sistema FreeBSD 14.0-RELEASE ou superior instalado, com acesso root (ou um usuário com sudo configurado). Recomendamos fortemente o uso de ZFS como sistema de arquivos, pois ele será fundamental para snapshots e recuperação. O servidor deve ter pelo menos duas interfaces de rede: uma para administração e outra para testes de firewall ou para a rede interna onde os serviços serão expostos. Em nossos laboratórios na JRT Technology Solutions, utilizamos máquinas virtuais com 2 vCPU, 4 GB de RAM e 20 GB de disco, o que é suficiente para todos os exemplos.

Além do servidor FreeBSD, você precisará de duas máquinas virtuais adicionais para instalar o pfSense e o OPNsense. Elas podem ter configurações modestas: 1 vCPU, 1 GB de RAM e disco de 8 GB. As ISOs podem ser baixadas diretamente dos sites oficiais — pfSense da Netgate e OPNsense da Deciso. Para gravar as ISOs em mídia física ou em hipervisor, você pode usar o dd no FreeBSD ou ferramentas gráficas como Rufus no Windows. Nesta aula, focaremos na instalação via console, que é o método mais comum em servidores e o mais didático.

Antes de começar, verifique se o sistema está atualizado e se os repositórios de pacotes estão funcionando. Execute os comandos abaixo como root. Eles atualizam a árvore de pacotes e instalam as ferramentas básicas que usaremos, como vim, curl e sudo. A saída esperada mostra o pkg sendo atualizado e os pacotes sendo instalados sem erros. Este passo é obrigatório para garantir que todas as dependências estejam disponíveis.

# Atualiza o catálogo de pacotes do FreeBSD
pkg update -f

# Instala ferramentas essenciais para administração e testes
pkg install -y vim-console curl sudo bash htop

# Verifica a versão do sistema e do kernel
freebsd-version -kru
uname -a

Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
The following 5 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
	bash: 5.2.37
	curl: 8.9.1
	htop: 3.3.0_2
	sudo: 1.9.15p5_4
	vim-console: 9.1.0502

Number of packages to be installed: 5
The process will require 58 MiB more space.
Proceed with this action? [y/N]: y
[1/5] Installing bash-5.2.37...
[2/5] Installing curl-8.9.1...
[3/5] Installing htop-3.3.0_2...
[4/5] Installing sudo-1.9.15p5_4...
[5/5] Installing vim-console-9.1.0502...
=====
Message from sudo-1.9.15p5_4:
--
To use sudo, you must configure the sudoers file. See sudoers(5).
=====
14.0-RELEASE-p10
14.0-RELEASE-p10
14.0-RELEASE-p10
FreeBSD fbsd-prod 14.0-RELEASE-p10 FreeBSD 14.0-RELEASE-p10 #0: Tue Sep  8 10:00:00 UTC 2026     root@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64

Com o ambiente básico pronto, você já pode avançar para as próximas seções. Verifique também se o serviço sshd está habilitado e se você consegue acessar o servidor remotamente. Em produção, a administração remota via SSH é a norma, e toda alteração deve ser feita com registro e controle de acesso. Se ainda não configurou o SSH, revisite a aula anterior sobre serviços de rede antes de prosseguir.

O que significa FreeBSD em produção

Quando falamos de FreeBSD em produção, estamos nos referindo ao uso do sistema operacional em ambientes onde a disponibilidade, a segurança e a previsibilidade são inegociáveis. Diferente de um sistema de testes, um servidor de produção exige que cada alteração seja planejada, testada e documentada. O FreeBSD oferece uma combinação única de ferramentas para isso: o ZFS para integridade de dados e snapshots, o pf para filtragem de pacotes com sintaxe expressiva, as jails para isolamento de serviços, e os ports/packages para instalação controlada de software. Essa base sólida é a razão pela qual gigantes como Netflix, WhatsApp e Juniper Networks confiam no FreeBSD para suas infraestruturas críticas.

Em um servidor corporativo FreeBSD, o kernel é o primeiro ponto de atenção. Os valores padrão de sysctl são conservadores e funcionam bem para desktops ou sistemas com pouca carga, mas em produção você precisará ajustar parâmetros de rede, memória e limites de arquivos abertos. Por exemplo, o parâmetro kern.ipc.somaxconn controla o tamanho da fila de conexões TCP pendentes, e aumentá-lo é essencial para servidores web com alto volume de acessos. Da mesma forma, net.inet.tcp.fastopen pode acelerar o estabelecimento de conexões TLS, e vfs.zfs.arc_max limita o uso de memória pelo cache do ZFS. Todos esses ajustes devem ser feitos com base em métricas reais, e não por intuição.

Outro pilar do FreeBSD em produção é o gerenciamento de atualizações. O comando freebsd-update permite aplicar patches de segurança sem recompilar o kernel, enquanto o pkg audit verifica vulnerabilidades conhecidas nos pacotes instalados. Automatizar essas verificações com cron ou com ferramentas de gerenciamento de configuração é uma prática obrigatória. Em nossos projetos na JRT Technology Solutions, configuramos freebsd-update cron para baixar e instalar patches automaticamente em janelas de manutenção predefinidas, com snapshots ZFS antes de cada atualização para permitir rollback instantâneo em caso de regressão.

O firewall pf é a espinha dorsal da segurança de rede no FreeBSD. Originalmente desenvolvido para o OpenBSD e portado para o FreeBSD, o pf permite escrever regras de filtragem, NAT, redirecionamento e QoS de forma clara e poderosa. Um servidor corporativo pode usar o pf para proteger seus próprios serviços, enquanto o pfSense e o OPNsense estendem essa mesma tecnologia para appliances de borda dedicados. Compreender o pf no FreeBSD é, portanto, compreender a base dos firewalls mais usados no mundo corporativo. Nos próximos blocos, vamos explorar essa relação em profundidade.

Finalmente, é importante destacar que FreeBSD em produção exige uma mentalidade de operação contínua. Monitoramento, logs centralizados, backups testados e plano de recuperação de desastres não são opcionais. Nesta aula, você verá como configurar o mínimo necessário para colocar um servidor em produção com segurança, mas lembre-se: cada ambiente é único, e as boas práticas devem ser adaptadas à sua realidade. O objetivo aqui é fornecer uma base sólida e funcional, não um modelo engessado.

Preparando o FreeBSD para cargas corporativas — tuning e hardening

Antes de instalar qualquer serviço, vamos preparar o sistema para suportar cargas de trabalho reais. Abra o arquivo /etc/sysctl.conf e adicione os parâmetros abaixo. Esses ajustes são amplamente testados em servidores FreeBSD e servem como ponto de partida para a maioria das cargas web e de banco de dados. O parâmetro kern.ipc.somaxconn aumenta a fila de conexões pendentes para 4096, evitando rejeições durante picos de acesso. O net.inet.tcp.syncookies ativa proteção contra ataques SYN flood. O vfs.zfs.arc_max limita o cache ARC do ZFS a 1 GB, liberando memória para aplicações — ajuste esse valor conforme a RAM total do seu servidor.

# /etc/sysctl.conf — Tuning para servidor corporativo FreeBSD
# Aumenta a fila de conexões TCP pendentes
kern.ipc.somaxconn=4096
# Ativa proteção contra SYN flood
net.inet.tcp.syncookies=1
# Permite reutilização rápida de sockets em TIME_WAIT
net.inet.tcp.fast_finwait2_recycle=1
# Aumenta buffers de rede para alta vazão
net.inet.tcp.sendbuf_max=16777216
net.inet.tcp.recvbuf_max=16777216
# Limita o cache ARC do ZFS a 1 GB (ajuste conforme necessário)
vfs.zfs.arc_max=1073741824
# Habilita encaminhamento de pacotes (necessário para roteamento e jails)
net.inet.ip.forwarding=1
# Aumenta limite de arquivos abertos para usuários
kern.maxfiles=65536
kern.maxfilesperproc=32768

Após editar o arquivo, aplique as alterações com o comando sysctl -f /etc/sysctl.conf. A saída esperada lista cada parâmetro com seu novo valor. Em seguida, edite o arquivo /boot/loader.conf para carregar módulos importantes no boot, como o pf (firewall), o accf_http (filtros de aceitação para HTTP, que melhoram desempenho do Nginx) e o nullfs (usado por jails). O conteúdo completo do arquivo está abaixo. Note que alguns parâmetros podem já existir; mantenha apenas uma ocorrência de cada para evitar conflitos.

# /boot/loader.conf — Módulos carregados no boot
# Carrega o firewall pf
pf_load="YES"
# Carrega filtros de aceitação para HTTP
accf_http_load="YES"
# Carrega o módulo nullfs para jails
nullfs_load="YES"
# Suporte a aesni para aceleração criptográfica (se disponível)
aesni_load="YES"

Com esses módulos carregados, reinicie o sistema para que as mudanças no loader.conf tenham efeito. Após o reboot, verifique se o módulo pf foi carregado corretamente com kldstat | grep pf. A saída deve mostrar uma linha contendo pf.ko. Esse é um passo essencial, pois o firewall é um componente central desta aula. Em seguida, crie um diretório para armazenar scripts de manutenção e backups, como /root/scripts, que usaremos mais adiante.

# Aplica as configurações de sysctl imediatamente
sysctl -f /etc/sysctl.conf

# Verifica se o módulo pf foi carregado
kldstat | grep pf

# Cria diretório para scripts administrativos
mkdir -p /root/scripts
chmod 700 /root/scripts

kern.ipc.somaxconn: 128 -> 4096
net.inet.tcp.syncookies: 0 -> 1
net.inet.tcp.fast_finwait2_recycle: 0 -> 1
net.inet.tcp.sendbuf_max: 262144 -> 16777216
net.inet.tcp.recvbuf_max: 262144 -> 16777216
vfs.zfs.arc_max: 0 -> 1073741824
net.inet.ip.forwarding: 0 -> 1
kern.maxfiles: 12328 -> 65536
kern.maxfilesperproc: 6164 -> 32768
 2    1 0xffffffff82a3d000    3c1a0 pf.ko

Além do tuning de kernel, o hardening básico inclui restringir o acesso SSH, configurar senhas fortes e remover serviços desnecessários. Verifique o arquivo /etc/rc.conf e certifique-se de que apenas os serviços essenciais estão habilitados. Em nossos servidores na JRT Technology Solutions, mantemos sshd_enable=”YES”, zfs_enable=”YES” e pf_enable=”YES”, desabilitando tudo o que não for estritamente necessário. Essa prática reduz a superfície de ataque e simplifica a manutenção. Abra o arquivo e confira cada linha antes de prosseguir.

Configurando o firewall pf em FreeBSD em produção

O firewall pf é a peça central da segurança de rede no FreeBSD. Sua configuração é feita no arquivo /etc/pf.conf, que segue uma sintaxe poderosa e expressiva. O arquivo é dividido em seções: macros (variáveis), tables (tabelas de endereços), options (parâmetros globais), normalization (normalização de pacotes), queueing (controle de banda), translation (NAT) e filter rules (regras de filtragem). Vamos criar uma configuração completa para um servidor corporativo que expõe serviços HTTP, HTTPS e SSH, permitindo também tráfego de saída para atualizações e monitoramento.

O conteúdo abaixo é o arquivo /etc/pf.conf completo, comentado linha por linha. A macro ext_if define a interface externa, que geralmente é em0 ou vtnet0 em VMs. As portas de serviços são definidas em macros para facilitar alterações. A tabela blocked_ips pode ser populada dinamicamente com endereços maliciosos, e a opção set skip on lo0 evita filtrar tráfego de loopback. As regras finais bloqueiam tudo por padrão (política default deny) e permitem apenas o necessário. Essa é a abordagem recomendada para produção: negar tudo e liberar pontualmente.

# /etc/pf.conf — Firewall corporativo para FreeBSD em produção
# Macros
ext_if="em0"                # Interface externa (ajuste conforme sua máquina)
ssh_port="22"               # Porta SSH
http_port="80"              # Porta HTTP
https_port="443"            # Porta HTTPS
icmp_types="echoreq"        # Tipos ICMP permitidos (apenas echo request)

# Tabelas
table  persist file "/etc/blocked_ips.txt"

# Opções
set block-policy drop        # Descarta pacotes bloqueados silenciosamente
set loginterface $ext_if     # Loga estatísticas da interface externa
set skip on lo0              # Não filtra loopback

# Normalização
scrub in all                 # Normaliza pacotes de entrada

# Regras de tradução (NAT) — descomente se o FreeBSD for roteador
# nat on $ext_if from 10.0.0.0/24 to any -> ($ext_if)

# Regras de filtragem
block all                     # Bloqueia tudo por padrão
block quick from   # Bloqueia IPs listados imediatamente
pass in on $ext_if proto tcp from any to ($ext_if) port { $ssh_port, $http_port, $https_port } flags S/SA keep state
pass in on $ext_if proto icmp from any to ($ext_if) icmp-type $icmp_types keep state
pass out on $ext_if proto { tcp, udp } from ($ext_if) to any keep state
pass out on $ext_if proto icmp from ($ext_if) to any keep state

Após criar o arquivo, é hora de criar a tabela de IPs bloqueados e testar a configuração antes de ativá-la. O comando pfctl -nf /etc/pf.conf faz uma verificação de sintaxe sem carregar as regras; se não houver erros, a saída será vazia. Em seguida, ative o firewall com pfctl -ef /etc/pf.conf e habilite-o permanentemente no /etc/rc.conf com pf_enable=”YES”. A saída esperada do pfctl -e mostra pf enabled, e o pfctl -sr lista as regras carregadas, confirmando que a política está ativa.

# Cria arquivo de IPs bloqueados (vazio por enquanto)
touch /etc/blocked_ips.txt

# Testa a sintaxe do arquivo pf.conf
pfctl -nf /etc/pf.conf

# Ativa o firewall e carrega as regras
pfctl -ef /etc/pf.conf

# Habilita o pf no boot
sysrc pf_enable="YES"
sysrc pflog_enable="YES"

# Exibe as regras carregadas
pfctl -sr

pf enabled
block drop all
block drop in quick from  to any
pass in on em0 proto tcp from any to 192.168.1.10 port = ssh flags S/SA keep state
pass in on em0 proto tcp from any to 192.168.1.10 port = http flags S/SA keep state
pass in on em0 proto tcp from any to 192.168.1.10 port = https flags S/SA keep state
pass in on em0 proto icmp from any to 192.168.1.10 icmp-type echoreq keep state
pass out on em0 proto tcp from 192.168.1.10 to any keep state
pass out on em0 proto udp from 192.168.1.10 to any keep state
pass out on em0 proto icmp from 192.168.1.10 to any keep state

Com o firewall ativo, teste a conectividade a partir de outra máquina. Você deve conseguir acessar as portas 22, 80 e 443 (se os serviços estiverem rodando), mas não outras portas. Para verificar em tempo real, use tcpdump na interface externa enquanto tenta uma conexão de fora. Se o pacote aparecer e depois for bloqueado, o pf está funcionando corretamente. Lembre-se de que o arquivo /etc/blocked_ips.txt pode ser alimentado com IPs maliciosos manualmente ou via scripts de automação, e a tabela é carregada no boot graças à opção persist.

Passo a passo: instalando Nginx e PostgreSQL em jails no FreeBSD em produção

Agora que o sistema base está endurecido, vamos instalar os serviços essenciais usando jails para isolamento. Jails são uma forma de virtualização em nível de sistema operacional nativa do FreeBSD, semelhante a containers, mas com um histórico de segurança e maturidade muito maior. Em um ambiente corporativo, é comum rodar o servidor web e o banco de dados em jails separadas, cada uma com seu próprio endereço IP e limites de recursos. Isso impede que uma vulnerabilidade em um serviço comprometa todo o host. Nesta seção, criaremos duas jails: webjail para Nginx e dbjail para PostgreSQL.

Antes de criar as jails, instale o pacote jailmanager ou use o utilitário nativo jail com arquivos de configuração. Para simplificar, usaremos o método clássico com jail.conf. Primeiro, baixe o sistema base para as jails usando bsdinstall jail ou, mais simplesmente, instale o pacote jailkit e use jail -c. Na prática, muitos administradores utilizam ezjail ou iocage; aqui, mostraremos o iocage, que é a ferramenta moderna recomendada para gerenciamento de jails. Execute os comandos abaixo para instalar e inicializar o iocage.

# Instala o iocage para gerenciamento de jails
pkg install -y iocage

# Inicializa o iocage no pool ZFS zroot (padrão)
iocage activate zroot

# Baixa a release 14.0-RELEASE para criação de jails (pode demorar)
iocage fetch release=14.0-RELEASE

# Cria a jail webjail com IP 10.0.0.10 e interface em0
iocage create -n webjail release=14.0-RELEASE ip4_addr="em0|10.0.0.10/24" defaultrouter="10.0.0.1" boot="on"

# Cria a jail dbjail com IP 10.0.0.11
iocage create -n dbjail release=14.0-RELEASE ip4_addr="em0|10.0.0.11/24" defaultrouter="10.0.0.1" boot="on"

# Inicia ambas as jails
iocage start webjail
iocage start dbjail

iocage activated on zroot
Fetching: 14.0-RELEASE
Extracting: base.txz
webjail successfully created!
dbjail successfully created!
* Starting webjail
  + Started OK
* Starting dbjail
  + Started OK

Com as jails rodando, acesse a jail webjail com o comando iocage console webjail e instale o Nginx. Dentro da jail, use o pkg normalmente, como se fosse um sistema FreeBSD independente. Após a instalação, edite o arquivo de configuração do Nginx para servir uma página simples de teste. O conteúdo completo do /usr/local/etc/nginx/nginx.conf está abaixo, configurado para escutar na porta 80 e servir arquivos estáticos de /usr/local/www/nginx. Observe que a diretiva listen 80 default_server; define este servidor como padrão para requisições sem cabeçalho Host específico.

# Dentro da jail webjail:
iocage console webjail

# Instala o Nginx
pkg install -y nginx

# Edite /usr/local/etc/nginx/nginx.conf conforme abaixo
vi /usr/local/etc/nginx/nginx.conf

# /usr/local/etc/nginx/nginx.conf — Configuração do Nginx na jail webjail
worker_processes  1;

events {
    worker_connections  1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;

    server {
        listen       80 default_server;
        server_name  localhost;

        location / {
            root   /usr/local/www/nginx;
            index  index.html index.htm;
        }

        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   /usr/local/www/nginx-dist;
        }
    }
}

Após salvar o arquivo, habilite o Nginx e inicie o serviço com sysrc nginx_enable=YES e service nginx start. Crie uma página HTML simples em /usr/local/www/nginx/index.html para testar. Em seguida, saia da jail com exit e repita o processo na dbjail para instalar o PostgreSQL. No PostgreSQL, ajuste o arquivo /var/db/postgres/data14/postgresql.conf para escutar em todos os endereços, definindo listen_addresses = ‘*’, e configure a autenticação no pg_hba.conf para permitir conexões da rede interna. Esses passos são detalhados a seguir.

# Dentro da jail dbjail:
iocage console dbjail

# Instala o PostgreSQL 14
pkg install -y postgresql14-server postgresql14-client

# Inicializa o banco de dados
service postgresql initdb

# Habilita e inicia o PostgreSQL
service postgresql enable
service postgresql start

# Edite os arquivos de configuração
vi /var/db/postgres/data14/postgresql.conf
vi /var/db/postgres/data14/pg_hba.conf

No arquivo postgresql.conf, altere a linha #listen_addresses = ‘localhost’ para listen_addresses = ‘*’ (remova o comentário e troque o valor). No arquivo pg_hba.conf, adicione uma linha no final para permitir conexões da rede 10.0.0.0/24 com senha. O conteúdo completo dos arquivos relevantes está abaixo. Essas alterações são necessárias porque, por padrão, o PostgreSQL só escuta em localhost, e as conexões da rede externa são rejeitadas. Em produção, é comum usar uma rede interna dedicada para o tráfego entre aplicação e banco, e o firewall pf no host deve permitir apenas essa comunicação.

# Trecho do postgresql.conf
listen_addresses = '*'          # what IP address(es) to listen on;
port = 5432                     # (change requires restart)
max_connections = 100           # (change requires restart)

# Linha adicionada ao pg_hba.conf
host    all             all             10.0.0.0/24            scram-sha-256

Com os serviços instalados e configurados, saia da jail e reinicie ambas para garantir que as configurações persistam. No host, use iocage restart webjail dbjail. Em seguida, teste a conectividade: a partir do host ou de outra máquina na rede 10.0.0.0/24, acesse http://10.0.0.10 e verifique se a página do Nginx é exibida. Para o banco, use psql -h 10.0.0.11 -U postgres e digite a senha configurada durante a inicialização. Se tudo funcionar, você tem uma arquitetura mínima de produção com isolamento de serviços via jails.

pfSense e OPNsense no contexto de FreeBSD em produção

O pfSense e o OPNsense são distribuições de firewall baseadas no FreeBSD e no filtro de pacotes pf. Eles empacotam o poder do FreeBSD em um appliance com interface web para facilitar a administração, adicionando funcionalidades como VPN, captive portal, balanceamento de carga e relatórios. Ambos são amplamente utilizados em ambientes corporativos, mas possuem filosofias diferentes: o pfSense tem foco em simplicidade e grande base de usuários, enquanto o OPNsense enfatiza atualizações mais frequentes, código mais próximo do upstream e uma interface mais moderna com busca integrada. Para quem administra servidores FreeBSD em produção, conhecer esses dois firewalls é essencial, pois eles frequentemente aparecem como solução de borda em redes que já utilizam o FreeBSD internamente.

A relação entre eles é tão próxima que o pfSense foi originalmente um fork do m0n0wall, que por sua vez era baseado no FreeBSD. O OPNsense, por sua vez, nasceu em 2014 como um fork do pfSense, mantendo a base FreeBSD mas adotando uma abordagem de desenvolvimento mais aberta e com lançamentos semestrais. Em nossos projetos na JRT Technology Solutions, frequentemente recomendamos o OPNsense para clientes que desejam um ciclo de atualização mais previsível e uma interface mais intuitiva, enquanto o pfSense é uma escolha sólida para quem precisa de ampla documentação e suporte comercial da Netgate. Ambos podem ser integrados a servidores FreeBSD via syslog, SNMP, VPN IPsec/OpenVPN e autenticação RADIUS, criando um ecossistema coeso.

Para esta aula, vamos instalar ambos em máquinas virtuais separadas, começando pelo pfSense. O processo de instalação é idêntico ao de um FreeBSD tradicional: você baixa a ISO, grava em mídia, inicializa e segue o instalador. A diferença é que, após a instalação, o pfSense apresenta um assistente de configuração via console e, em seguida, uma interface web para gerenciamento. Vamos detalhar cada passo, incluindo a configuração de interfaces, regras de firewall e testes de conectividade. O mesmo faremos com o OPNsense, destacando as diferenças e a integração com o servidor FreeBSD que preparamos anteriormente.

Passo a passo: implantando pfSense em ambiente corporativo

Comece baixando a imagem ISO do pfSense Community Edition no site oficial da Netgate. Grafe a ISO em uma mídia USB ou utilize-a diretamente em um hipervisor como VirtualBox, VMware ou Proxmox. Crie uma máquina virtual com duas interfaces de rede: a primeira conectada à sua rede externa (WAN) e a segunda a uma rede interna (LAN). Inicialize a VM e siga o instalador. Na primeira tela, selecione Install, escolha o disco e confirme a formatação. O instalador do pfSense é derivado do bsdinstall do FreeBSD e não requer interação complexa. Após reiniciar, você verá o menu console do pfSense com opções para configurar interfaces.

No menu console, selecione a opção 1) Assign Interfaces. Atribua a primeira interface como WAN e a segunda como LAN. Em seguida, selecione 2) Set interface IP address para configurar a WAN com IP da sua rede externa (por exemplo, 192.168.1.50/24) e a LAN com um IP interno (por exemplo, 10.0.1.1/24). O pfSense usará esses IPs para rotear o tráfego entre as redes. Após configurar, acesse a interface web de outra máquina na rede LAN usando http://10.0.1.1 (ou https com certificado autoassinado). O usuário padrão é admin e a senha pfsense, que deve ser alterada imediatamente.

# Comandos executados no console do pfSense (após instalação):
# 1. Assign Interfaces
#    WAN -> em0
#    LAN -> em1
# 2. Set interface IP address
#    WAN -> 192.168.1.50/24
#    LAN -> 10.0.1.1/24
# 3. Reset webConfigurator password (opcional, mas recomendado)
#    Define nova senha admin

# Após configurar, verifique a conectividade a partir do console:
ping -c 3 8.8.8.8

# Saída esperada (parcial):
# PING 8.8.8.8 (8.8.8.8): 56 data bytes
# 64 bytes from 8.8.8.8: icmp_seq=0 ttl=117 time=12.3 ms
# 64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=11.8 ms
# 64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=12.1 ms
# --- 8.8.8.8 ping statistics ---
# 3 packets transmitted, 3 packets received, 0.0% packet loss

Com o pfSense acessível via web, faça login e configure as regras de firewall. Por padrão, o pfSense bloqueia a entrada na WAN e permite a saída da LAN. Para liberar acesso à interface web a partir da LAN, a regra já existe. Para testar o funcionamento, conecte um servidor FreeBSD (ou qualquer máquina) na rede LAN com IP 10.0.1.10 e gateway 10.0.1.1. A partir dessa máquina, tente acessar a internet: curl https://www.freebsd.org. Se a conexão funcionar, o pfSense está roteando e NATeando corretamente. Você também pode criar regras de bloqueio ou liberação específicas na interface web, que são convertidas em regras do pf por baixo dos panos.

Para integração com o servidor FreeBSD corporativo que configuramos anteriormente, configure o syslog remoto no pfSense. Vá em Status > System Logs > Settings, ative

Quer aprender na prática com especialistas?

A JRT Technology Solutions oferece treinamentos e implementação de FreeBSD para equipes corporativas.

Falar no WhatsApp