Aula 19: Segurança FreeBSD — hardening, auditoria e Capsicum

Bem-vindo à Aula 19 do curso FreeBSD — Do Zero ao Avançado. Nesta etapa, vamos mergulhar fundo no tema Segurança FreeBSD, abordando três pilares fundamentais para qualquer profissional de infraestrutura, segurança da informação ou administração de sistemas: o endurecimento do sistema operacional (hardening), a auditoria de eventos e trilhas de segurança, e o uso do framework Capsicum para isolamento de processos e privilégios. Esta é uma aula de nível intermediário, projetada para consolidar o conhecimento adquirido nas aulas anteriores e transformar você em um administrador capaz de blindar servidores FreeBSD contra uma ampla gama de ameaças.

O FreeBSD é reconhecido mundialmente por sua robustez, estabilidade e excelente reputação em segurança. No entanto, nenhum sistema operacional é seguro por padrão — ele se torna seguro quando configurado corretamente, monitorado continuamente e quando as aplicações são executadas com o menor privilégio possível. A Segurança FreeBSD não é um produto que se instala; é um conjunto de práticas, configurações e ferramentas nativas que, quando aplicadas em camadas, reduzem drasticamente a superfície de ataque e aumentam a capacidade de detecção e resposta a incidentes.

Ao longo desta aula, você aprenderá a aplicar técnicas de hardening no kernel e no userspace, configurar parâmetros de sysctl que alteram o comportamento do sistema em nível de segurança, ativar e refinar o PF (firewall nativo), estruturar uma auditoria completa com o subsistema auditd, e implementar o Capsicum para criar processos confinados em sandbox. Também veremos como verificar cada configuração, como interpretar as saídas dos comandos e como diagnosticar os erros mais comuns que ocorrem em ambientes de produção.

Os pré-requisitos para esta aula incluem um sistema FreeBSD instalado (versão 13 ou 14, preferencialmente), acesso root, conhecimentos básicos de shell (sh/csh), edição de arquivos com vi ou ee, e familiaridade com o conceito de jails e permissões Unix introduzidos nas aulas anteriores. Se você seguiu o curso até aqui, já tem a base necessária. Ao final desta aula, você será capaz de implementar um conjunto de controles de segurança auditáveis e replicáveis em qualquer servidor FreeBSD, além de compreender os mecanismos responsáveis por isolar processos e limitar o impacto de uma eventual exploração de vulnerabilidades.

Em nossos projetos na JRT Technology Solutions, utilizamos diariamente as técnicas apresentadas aqui para fortalecer servidores de clientes, especialmente em ambientes de borda, bancos de dados e infraestrutura crítica. Nossos especialistas combinam o endurecimento do kernel com auditoria ativa e sandboxing via Capsicum para garantir que cada camada do sistema resista a ataques e registre evidências suficientes para análise forense. Agora, vamos colocar a mão na massa.

O que você vai aprender nesta aula

• Compreender os fundamentos da Segurança FreeBSD e o modelo de ameaças aplicado a servidores Unix.
• Aplicar endurecimento via sysctl e módulos de kernel, alterando parâmetros críticos de segurança.
• Configurar o firewall PF com regras práticas para proteger serviços de rede.
• Ativar e gerenciar o subsistema de auditoria auditd, gerando trilhas de eventos com praudit.
• Escrever, compilar e testar um programa em C utilizando o framework Capsicum para restrição de capacidades.
• Verificar cada configuração por meio de comandos de teste e análise de saídas esperadas.
• Diagnosticar e corrigir os erros mais comuns encontrados durante o hardening e a auditoria.
• Aplicar boas práticas avançadas, como securelevel, jails e monitoramento contínuo.

Pré-requisitos e Ambiente

Antes de iniciar os procedimentos práticos desta aula, certifique-se de que você possui um ambiente FreeBSD funcional. O ideal é uma máquina virtual ou servidor dedicado executando FreeBSD 13.x ou 14.x-RELEASE, pois esses ramos incluem todas as funcionalidades de segurança que vamos explorar. Você precisa de acesso root para alterar arquivos em /etc, carregar módulos do kernel e reiniciar serviços. Se estiver utilizando um servidor em produção, execute as mudanças em uma janela de manutenção e tenha acesso a um console de recuperação, pois algumas configurações de hardening podem impactar a conectividade ou o comportamento de aplicações.

Os principais diretórios e arquivos que manipularemos são: /etc/sysctl.conf (parâmetros do sistema persistidos), /boot/loader.conf (módulos e parâmetros carregados no boot), /etc/rc.conf (serviços e configurações de inicialização), /etc/pf.conf (regras do firewall PF) e /etc/security/ (configurações de auditoria). Recomendo que você tenha familiaridade com o editor vi ou ee e saiba verificar o estado de serviços com service e sysrc. Todos os comandos mostrados foram testados em FreeBSD 14.0-RELEASE, mas são compatíveis com a série 13.x.

Além disso, certifique-se de que o repositório de pacotes está atualizado, pois instalaremos algumas ferramentas complementares de auditoria e monitoramento. Se você não tem uma instalação limpa, prepare um snapshots ou backup antes de prosseguir. Em nossos treinamentos na JRT Technology Solutions, sempre recomendamos que os alunos pratiquem primeiro em uma VM descartável, pois alguns parâmetros de segurança — como securelevel elevado — exigem reinicialização para serem revertidos.

Por fim, verifique a versão do sistema e o estado atual dos serviços com os comandos abaixo. Eles fornecem uma linha de base que será útil para comparar o antes e o depois do hardening. Execute como root e observe as saídas.

# Verifica a versão do FreeBSD
freebsd-version

# Atualiza a base do sistema e os pacotes
freebsd-update fetch install
pkg update
pkg upgrade

# Exibe o estado dos serviços ativos
service -e

# Mostra o conteúdo atual das variáveis de inicialização
sysrc -a

14.0-RELEASE-p3
Fetching metadata...
Preparing to download files...
The following packages will be upgraded:
        ...
Number of packages to be upgraded: 12
Proceed with this action? [y/N]: y
...
/etc/rc.conf: sshd_enable="YES"
/etc/rc.conf: dumpdev="AUTO"
/etc/rc.conf: zfs_enable="YES"

A saída acima confirma um FreeBSD 14.0-RELEASE com o SSH habilitado e ZFS ativo. A partir desse ponto, vamos começar o processo de endurecimento.

Fundamentos da Segurança FreeBSD — superfície de ataque e modelo de ameaças

Para aplicar a Segurança FreeBSD de forma eficaz, é essencial compreender o conceito de superfície de ataque. Em qualquer sistema operacional, a superfície de ataque é o conjunto de interfaces, processos, portas de rede, serviços e componentes do kernel que podem ser acessados por um agente malicioso. Quanto maior essa superfície, maiores são as chances de que uma configuração incorreta, um bug ou uma vulnerabilidade seja explorada. O objetivo do hardening é justamente reduzir a superfície de ataque ao mínimo necessário para que o sistema cumpra sua função.

No FreeBSD, a superfície de ataque pode ser dividida em três grandes áreas: o kernel, os processos do userspace e a rede. O kernel expõe chamadas de sistema (syscalls) e interfaces de configuração como o sysctl. Os processos do userspace incluem daemons como sshd, cron, syslogd e serviços de rede. A camada de rede, por sua vez, é controlada pelo firewall e pelas configurações de pilha TCP/IP. O hardening atua em todas essas camadas, aplicando o princípio do menor privilégio e removendo funcionalidades desnecessárias.

Um dos recursos mais poderosos do FreeBSD para segurança é o securelevel (nível de segurança do kernel). Quando configurado acima de zero, o securelevel restringe operações como a modificação de certos parâmetros do kernel, a montagem de sistemas de arquivos com devfs e a gravação em memória física. Outro recurso é o sysctl, que permite ajustar dezenas de parâmetros de segurança sem recompilar o kernel, como esconder processos de outros usuários, randomizar PIDs e controlar o encaminhamento de pacotes. Vamos explorar esses mecanismos nas próximas seções.

Além do hardening do sistema base, a auditoria é um componente essencial da Segurança FreeBSD. O subsistema auditd registra eventos de segurança em arquivos binários que podem ser analisados com a ferramenta praudit. Diferentemente de simples logs do syslog, a auditoria fornece um registro estruturado e à prova de adulteração de atividades como logins, mudanças de permissões, execuções de comandos e acessos a arquivos. Quando combinada com um firewall bem configurado e com o Capsicum, a auditoria transforma o FreeBSD em uma plataforma extremamente defensável.

No contexto de ameaças reais, nossos analistas da JRT Technology Solutions frequentemente encontram ataques que exploram configurações padrão, como o sysctl security.bsd.see_other_uids habilitado, que permite a um usuário ver processos de outros usuários. Esse tipo de informação vaza detalhes sobre serviços em execução e pode ser usado em fases de reconhecimento. Corrigir esses desvios é o primeiro passo para uma postura de segurança madura. Vamos agora aplicar essas correções de forma sistemática.

Endurecendo o Kernel — parâmetros de sysctl e módulos

O primeiro passo prático do hardening é ajustar os parâmetros do kernel via sysctl. Esses parâmetros controlam o comportamento do sistema em tempo real e podem ser definidos de forma persistente no arquivo /etc/sysctl.conf. A aplicação correta desses ajustes reduz a superfície de ataque e mitiga várias classes de ataques, como a enumeração de processos, o spoofing de endereços IP e a propagação de pacotes maliciosos na rede interna. Vamos executar os comandos abaixo para aplicar as alterações imediatamente e, em seguida, persistir as configurações.

Cada comando sysctl recebe o nome do parâmetro e o valor desejado. Por exemplo, sysctl security.bsd.see_other_uids=0 impede que usuários comuns vejam processos pertencentes a outros UIDs. O valor 0 significa desabilitado, enquanto 1 habilita. A flag -w é opcional, mas deixa explícita a intenção de escrita. Após executar cada comando, o sysctl exibe o valor antigo e o novo, permitindo confirmar a alteração. Vamos começar com um bloco completo de hardening de kernel.

# Impede usuários de ver processos de outros UIDs
sysctl -w security.bsd.see_other_uids=0

# Impede usuários de ver processos de outros GIDs
sysctl -w security.bsd.see_other_gids=0

# Impede usuários de ver informações detalhadas de processos de outros usuários
sysctl -w security.bsd.see_other_uids=0
sysctl -w security.bsd.see_other_gids=0

# Gera PIDs aleatórios para dificultar ataques de previsão de PID
sysctl -w kern.randompid=1

# Desabilita o encaminhamento de IP (IPv4 e IPv6)
sysctl -w net.inet.ip.forwarding=0
sysctl -w net.inet6.ip6.forwarding=0

# Desabilita a resposta a pacotes ICMP broadcast
sysctl -w net.inet.icmp.bmcastecho=0

# Ignora pacotes ICMP redirect (evita envenenamento de rotas)
sysctl -w net.inet.icmp.drop_redirect=1
sysctl -w net.inet6.icmp6.rediraccept=0

# Habilita proteção contra SYN flood e sincookies
sysctl -w net.inet.tcp.syncookies=1
sysctl -w net.inet.tcp.blackhole=2
sysctl -w net.inet.udp.blackhole=1

# Restringe o uso de core dump em caso de falhas de segurança
sysctl -w kern.corefile=/dev/null
sysctl -w security.bsd.unprivileged_read_msgbuf=1

# Impede que usuários montem sistemas de arquivos via devfs
sysctl -w vfs.usermount=0

security.bsd.see_other_uids: 1 -> 0
security.bsd.see_other_gids: 1 -> 0
kern.randompid: 0 -> 1
net.inet.ip.forwarding: 0 -> 0
net.inet.icmp.bmcastecho: 1 -> 0
net.inet.icmp.drop_redirect: 1 -> 1
net.inet.tcp.syncookies: 1 -> 1
net.inet.tcp.blackhole: 0 -> 2
net.inet.udp.blackhole: 0 -> 1
kern.corefile: /var/coredumps/%N.core -> /dev/null
vfs.usermount: 1 -> 0

As saídas mostram cada parâmetro seguido de sua transição do valor antigo para o novo. É importante notar que alguns parâmetros já podem estar definidos no valor desejado, o que não é um problema. O parâmetro kern.randompid=1 faz com que o kernel atribua PIDs de forma pseudoaleatória, dificultando ataques que dependem da previsão de identificadores de processo. Já net.inet.tcp.blackhole=2 faz com que o sistema descarte silenciosamente pacotes para portas fechadas, tornando o escaneamento de portas mais lento e menos confiável para o atacante.

Além dos parâmetros de sysctl, o FreeBSD permite desabilitar módulos do kernel que não são necessários. Por exemplo, se você não usa IPv6, pode desabilitá-lo no boot para reduzir a superfície de ataque. Se você não usa o suporte a SysV IPC ou a Acct (contabilidade de processos), também pode removê-los. Essas configurações são feitas no arquivo /boot/loader.conf. A desabilitação de módulos deve ser feita com cuidado, pois alguns serviços dependem deles. Em nossos projetos na JRT Technology Solutions, recomendamos desabilitar apenas o que for comprovadamente desnecessário.

Para aplicar os parâmetros de forma persistente, crie ou edite o arquivo /etc/sysctl.conf e adicione as linhas equivalentes. A próxima seção mostra o conteúdo completo desse arquivo, juntamente com o loader.conf, para que você possa copiar e personalizar conforme seu ambiente.

Configuração Detalhada — /etc/sysctl.conf e /boot/loader.conf

A persistência das configurações de segurança é crucial: em um reboot, o kernel retornaria aos valores padrão se as alterações não estivessem em arquivos de configuração. O arquivo /etc/sysctl.conf é lido pelo init no início do boot e aplica os parâmetros via sysctl. Já o /boot/loader.conf é processado pelo carregador do kernel e permite carregar ou desabilitar módulos antes mesmo do kernel terminar a inicialização. Vamos criar ambos com um conteúdo completo e comentado.

No sysctl.conf, cada linha segue o formato parametro=valor, sem o prefixo sysctl -w. Comentários iniciam com #. É uma boa prática agrupar os parâmetros por categoria (kern, security, net, vfs). Abaixo, o conteúdo completo que recomendamos para um servidor de uso geral, com explicações em linha.

# /etc/sysctl.conf — Configuração de segurança FreeBSD (Aula 19)
# Aplicado automaticamente no boot pelo init

# --- Segurança de processos e visibilidade ---
security.bsd.see_other_uids=0     # Esconde processos de outros usuários
security.bsd.see_other_gids=0     # Esconde processos de outros grupos
kern.randompid=1                   # PIDs aleatórios (anti-exploitation)
kern.corefile=/dev/null            # Descarta core dumps (anti-forense reversa)

# --- Rede: proteção contra spoofing e flood ---
net.inet.ip.forwarding=0           # Não roteia pacotes IPv4
net.inet6.ip6.forwarding=0         # Não roteia pacotes IPv6
net.inet.icmp.bmcastecho=0         # Ignora ICMP broadcast
net.inet.icmp.drop_redirect=1      # Descarta ICMP redirect IPv4
net.inet6.icmp6.rediraccept=0      # Descarta ICMP redirect IPv6
net.inet.tcp.syncookies=1          # Ativa syncookies contra SYN flood
net.inet.tcp.blackhole=2           # Blackhole para portas TCP fechadas
net.inet.udp.blackhole=1           # Blackhole para portas UDP fechadas

# --- Sistema de arquivos e montagem ---
vfs.usermount=0                    # Impede montagens por usuários comuns

# --- Restrição de mensagens do kernel ---
security.bsd.unprivileged_read_msgbuf=1  # Impede leitura do msgbuf por não-root

No loader.conf, podemos desabilitar módulos desnecessários. Por exemplo, se o servidor não utiliza IPv6, adicionamos ipv6_load="NO" e ipv6_ipv4mapping="NO". Se não utiliza o suporte a SysV semaphores ou shared memory, podemos desabilitar sem_load="NO" e shm_load="NO". Caso utilize ZFS, não desabilite os módulos relacionados. O conteúdo abaixo é um exemplo para um servidor web com ZFS e sem IPv6.

# /boot/loader.conf — Módulos de kernel (Aula 19)
# Processado pelo carregador antes do init

# ZFS é essencial: mantém o suporte ativo
zfs_load="YES"

# Desabilita IPv6 se não for utilizado
ipv6_load="NO"
ipv6_ipv4mapping="NO"

# Desabilita módulos de IPC SysV se não forem necessários
sem_load="NO"
shm_load="NO"

# Ativa módulos de segurança adicionais
auditd_load="YES"  # Carrega o módulo de auditoria no boot

Após editar os arquivos, valide a sintaxe do sysctl.conf executando sysctl -f /etc/sysctl.conf e observe se todas as linhas são aplicadas sem erros. Para o loader.conf, a validação ocorre no próximo boot, mas você pode verificar os módulos ativos com kldstat. Em seguida, reinicie o sistema ou aplique os parâmetros manualmente. A tabela abaixo resume os parâmetros mais importantes e seu impacto na Segurança FreeBSD.

Firewall com PF — instalação, configuração e regras

O PF (Packet Filter) é o firewall nativo do FreeBSD, portado do OpenBSD. Ele oferece filtragem de pacotes com stateful inspection, NAT, redirecionamento de portas e integração com o pflog para registro de pacotes bloqueados. A configuração do PF é um dos pilares da Segurança FreeBSD, pois permite bloquear acessos não autorizados, limitar conexões por IP e aplicar políticas de tráfego. Diferentemente de outros firewalls, o PF no FreeBSD já vem no kernel base, bastando ativá-lo e escrever as regras no arquivo /etc/pf.conf.

Antes de ativar o PF, é importante planejar as regras com base nos serviços que devem permanecer acessíveis. Em um servidor web típico, permitimos SSH (porta 22) para administração, HTTP (80) e HTTPS (443) para o público, e bloqueamos todo o resto. Também permitimos tráfego de loopback (lo0) e ICMP para diagnóstico. O PF processa as regras na ordem em que aparecem; a última regra de block all garante a política de negação padrão. Vamos criar o arquivo completo.

# /etc/pf.conf — Firewall PF para servidor web (Aula 19)
# Política: negar tudo por padrão, permitir apenas o necessário

# Interface externa (ajuste para o nome da sua interface)
ext_if = "vtnet0"

# Portas de serviço permitidas
ssh_port = "22"
web_ports = "{ 80, 443 }"

# Normalização de pacotes (evita pacotes malformados)
scrub in all

# Tabela de endereços bloqueados (pode ser preenchida dinamicamente)
table <bruteforce> persist

# Bloqueia endereços da tabela de bruteforce
block quick from <bruteforce>

# Regras de loopback
pass quick on lo0

# Permite tráfego estabelecido
pass out on $ext_if keep state
pass in on $ext_if proto tcp from any to $ext_if port $ssh_port keep state (max-src-conn 5, max-src-conn-rate 5/60, overload <bruteforce> flush global)
pass in on $ext_if proto tcp from any to $ext_if port $web_ports keep state

# Bloqueia e registra todo o resto
block log on $ext_if all

No arquivo acima, a macro ext_if define a interface externa; ajuste para em0, igb0 ou o nome real do seu ambiente. A tabela bruteforce é usada para bloquear IPs que excedem o limite de conexões SSH. A regra de SSH limita a 5 conexões simultâneas por IP e 5 novas conexões por minuto, enviando o infrator para a tabela bruteforce com overload. A regra final block log registra pacotes bloqueados em pflog, permitindo auditoria posterior.

Após criar o arquivo, ative o PF no /etc/rc.conf e inicie o serviço. Use o comando sysrc para adicionar as variáveis de inicialização e o service para carregar as regras. Depois, verifique o estado do firewall com pfctl. A sequência completa é mostrada abaixo.

# Ativa o PF e o pflog no boot
sysrc pf_enable="YES"
sysrc pflog_enable="YES"

# Inicia o serviço do PF (ou recarrega se já estiver ativo)
service pf start
service pflog start

# Carrega as regras do arquivo
pfctl -f /etc/pf.conf

# Exibe as regras ativas
pfctl -sr

# Exibe estatísticas de tráfego e pacotes bloqueados
pfctl -s info

Enabling pf.
Enabling pflog.
pf enabled
ruleset loaded
pass quick on lo0 all flags S/SA keep state
pass out on vtnet0 all flags S/SA keep state
pass in on vtnet0 proto tcp from any to 192.168.1.10 port = ssh flags S/SA keep state (source-track rule, max-src-conn 5, max-src-conn-rate 5/60, overload <bruteforce> flush global)
pass in on vtnet0 proto tcp from any to 192.168.1.10 port = http flags S/SA keep state
pass in on vtnet0 proto tcp from any to 192.168.1.10 port = https flags S/SA keep state
block log on vtnet0 all

A saída de pfctl -sr mostra as regras carregadas e validadas, com a sintaxe expandida. Observe que a interface vtnet0 foi substituída pelo valor da macro ext_if. Nesse ponto, o firewall está ativo e aplicando a política de negação padrão. Teste o acesso SSH e HTTP a partir de um host externo para garantir que as regras permitem o tráfego legítimo e bloqueiam portas não listadas. Use pfctl -s info para ver os contadores de pacotes bloqueados e passados.

Em nossos projetos na JRT Technology Solutions, sempre implementamos o PF com regras de limitação de conexão para SSH e tabelas de overload, pois ataques de força bruta são extremamente comuns. Além disso, recomendamos o uso de block log para alimentar sistemas de monitoramento e detecção de intrusões. O PF é uma peça central da Segurança FreeBSD e deve ser revisado periodicamente.

Auditoria de Segurança FreeBSD — logs, auditd e trilhas de eventos

A auditoria é o olho que nunca pisca da Segurança FreeBSD. Enquanto o firewall bloqueia acessos indevidos, o subsistema de auditoria registra o que aconteceu dentro do sistema: logins, comandos executados, arquivos acessados, mudanças de privilégios e muito mais. O FreeBSD implementa auditoria baseada no padrão Basic Security Module (BSM), herdado do Solaris, com o daemon auditd responsável por coletar os eventos e gravá-los em arquivos binários no diretório /var/audit. Esses arquivos podem ser analisados com a ferramenta praudit ou enviados para sistemas de SIEM.

Para ativar a auditoria, primeiro configure o arquivo /etc/security/audit_control, que define o diretório de trilhas, as políticas, os eventos globais e o tamanho máximo dos arquivos. Em seguida, edite o /etc/security/audit_user para especificar classes de eventos específicas para usuários críticos, como o root. Por fim, habilite o serviço no rc.conf e inicie o auditd. O conteúdo completo do audit_control é mostrado abaixo.

# /etc/security/audit_control — Configuração da auditoria (Aula 19)
# Definição das trilhas e políticas do auditd

dir:/var/audit                   # Diretório onde as trilhas são gravadas
dist:off                         # Distribuição de trilha (off para não distribuir)
flags:lo,aa,pc,fd,fm             # Eventos globais: login, auth, processo, file, file_modify
minfree:5                        # Mínimo de 5% de espaço livre antes de parar a auditoria
naflags:lo,aa,pc,fd,fm           # Eventos para ações não atribuíveis (ex: falhas de login)
policy:cnt,argv,arge,seq        # Políticas: contar, incluir argv, incluir arge, incluir sequência
filesz:64M                       # Tamanho máximo de cada arquivo de trilha
expire-after:10M                 # Mantém trilhas por no máximo 10 minutos antes de rotacionar

No arquivo acima, a flag flags define as classes de eventos auditados globalmente. As classes usadas são: lo (login/logout), aa (autenticação/autorização), pc (processo/criação/exclusão), fd (acesso a arquivos) e fm (modificação de arquivos). A política cnt inclui a contagem de eventos, argv e arge registram os argumentos de linha de comando e ambiente, e seq inclui um número de sequência para detectar trilhas adulteradas. Ajuste conforme sua necessidade, mas cuidado para não gerar volume excessivo de dados.

Após configurar o audit_control, habilite e inicie o serviço. O módulo do kernel audit é carregado automaticamente pelo auditd, mas você pode carregá-lo manualmente com kldload audit para garantir. Para rotacionar e criar uma nova trilha de auditoria, use o comando audit -n. Para verificar o status atual, use audit -s. Para ler os arquivos de trilha, utilize praudit apontando para o arquivo desejado. A sequência completa é mostrada abaixo.

# Carrega o módulo de auditoria do kernel
kldload audit

# Habilita o auditd no boot
sysrc auditd_enable="YES"

# Inicia o serviço de auditoria
service auditd start

# Verifica o status da auditoria
audit -s

# Cria uma nova trilha de auditoria (rotação manual)
audit -n

# Lista os arquivos de trilha no diretório padrão
ls -lh /var/audit/

# Lê a trilha mais recente com praudit
praudit /var/audit/$(ls -t /var/audit/ | head -n 1)

Starting auditd.
audit status: enabled, active, directory=/var/audit, filesz=64M
-rw-------  1 audit  audit  256K Sep  7 10:15 20260907101500.not_terminated
header,94,11,login,0,Mon Sep  7 10:15:00 2026, + 00
subject,-1,root,root,root,root,0,root
return,success,0
header,210,11,execve(2),0,Mon Sep  7 10:15:00 2026, + 00
subject,1234,user1,users,user1,users,0,user1
return,success,0
path,/usr/bin/ls
attribute,100755,root,wheel,0,0,0
exec_arg,ls,-lh,/var/audit/

A saída do praudit exibe registros estruturados, incluindo header, subject, return e detalhes do evento. No exemplo, vemos um registro de execve do comando ls executado pelo usuário user1, com sucesso. Essa capacidade de reconstruir as ações dos usuários é essencial para auditoria forense e conformidade. Em projetos com requisitos de PCI-DSS ou LGPD, a auditoria BSM do FreeBSD atende às exigências de registro de acesso e monitoramento contínuo.

A tabela abaixo resume os comandos essenciais de auditoria que você utilizará no dia a dia, bem como seus usos mais comuns.

Capsicum — sandbox e privilégios no FreeBSD

O Capsicum é um framework de sandboxing e separação de privilégios nativo do FreeBSD, desenvolvido pela Universidade de Cambridge e integrado ao kernel desde a versão 10. Ele permite que um processo restrinja suas próprias capacidades (capabilities) de forma irreversível, limitando drasticamente o dano que pode causar em caso de vulnerabilidade. Com o Capsicum, um programa pode entrar em um modo de capacidade após abrir os recursos necessários e, em seguida, reduzir seus privilégios para apenas ler, escrever ou executar operações específicas, desabilitando todas as outras syscalls.

O modo Capsicum funciona combinando duas primitivas principais: cap_enter() e cap_rights_limit(). A primeira coloca o processo em modo de capacidade, no qual todas as operações globais são negadas