AppArmor em Debian — Guia Prático: Como Confinar o Nginx e Bases de Dados para Bloquear Ataques

A Grande Falha das Permissões Comuns: Porque o Controlo DAC Não Te Protege

Como administrador de sistemas, foste ensinado a configurar utilizadores, grupos e máscaras de permissões como chmod 644 ou 755. Configuras a tua aplicação web para correr sob o utilizador de sistema www-data, proteges as pastas sensíveis e assumes que o teu servidor Linux está seguro.

Este modelo clássico chama-se Discretionary Access Control (DAC). E perante uma vulnerabilidade de execução remota de código (RCE) ou uma falha num módulo PHP, o modelo DAC falha redondamente.

O RISCO DO CONTROLO TRADICIONAL DE ACESSO (DAC)

• O Atacante Explora uma Falha RCE → Nginx / PHP-FPM (www-data)
• Permitido pelo DAC:: Ler o ficheiro /etc/passwd • Ver logs do sistema em /var/log • Espiar outros sites em /var/www
• Permitido pelo DAC:: Escrever scripts executáveis em /tmp • Varrer a rede local com sockets • Descarregar ferramentas de ataque

No modelo DAC, qualquer processo tem exatamente os mesmos direitos do utilizador que o iniciou. Se o teu Nginx ou PHP estiver a correr como www-data, um atacante que consiga injetar código pode ler qualquer ficheiro do teu servidor que tenha permissão de leitura para “outros” (incluindo ficheiros de configuração e listas de utilizadores). Pior ainda: pode invocar /bin/bash ou /usr/bin/curl para descarregar malware para a pasta /tmp e abrir uma ligação reversa para o exterior.

É aqui que entra o Mandatory Access Control (MAC). No Debian GNU/Linux, o AppArmor funciona como um escudo no próprio kernel: ignora quem é o utilizador e restringe o que o programa pode fazer com base exclusiva no caminho do ficheiro binário.

Na nossa arquitetura de alojamento gerido e nas nossas sessões de consultoria técnica, consideramos o AppArmor uma linha de defesa obrigatória para impedir que uma falha na web se transforme num assalto ao servidor.

Como Funciona o AppArmor: Confinamento por Caminhos no Kernel Linux

Ao contrário do SELinux—que obriga a marcar etiquetas especiais nos inodes do disco e quebra frequentemente se moveres ficheiros sem cuidado—o AppArmor funciona com caminhos de ficheiros diretos e compreensíveis por qualquer pessoa.

Sempre que um processo faz uma chamada de sistema como sys_open, sys_execve ou sys_connect, a camada Linux Security Modules (LSM) trava o pedido antes de ele chegar ao sistema de ficheiros. Se o binário tiver um perfil de AppArmor associado, o kernel consulta a tabela de permissões:

INTERCEÇÃO DE CHAMADAS NO KERNEL COM LSM

• Binário da Aplicação: /usr/sbin/nginx
• Chamada de Sistema: sys_open(“/var/www/site/index.html”, O_RDONLY)
• Verificação Normal POSIX DAC: Aprovada (www-data tem permissão de leitura)
• INTERCEÇÃO DO APPARMOR VIA LSM: Regra Encontrada: “/var/www/ r” → PERMITIDO
• Resultado: O kernel entrega o ficheiro ao Nginx.
• Tentativa Maliciosa: sys_execve(“/bin/bash”, [“bash”, “-i”])
• Verificação Normal POSIX DAC: Aprovada (Binário 755 executável por todos)
• INTERCEÇÃO DO APPARMOR VIA LSM: Regra Encontrada: NENHUMA REGRA PERMITE /bin/bash PARA O NGINX
• Resultado: BLOQUEADO PELO KERNEL (EACCES) → Registo gravado no audit.log

Repara no que acontece: mesmo que o processo web tenha sido manipulado por um invasor e tente ler ficheiros protegidos, escrever na pasta temporária /tmp ou abrir uma shell de comandos, o próprio kernel do Linux cancela a operação com o erro Permission denied. O ataque morre na memória antes de tocar no teu sistema operativo.

Mãos à Obra: Como Confinar o Servidor Nginx no Teu Debian 12

Vamos construir um perfil de proteção real para o servidor web Nginx. O Debian já vem com o AppArmor ativado de fábrica, mas o Nginx geralmente não vem confinado. Vamos mudar isso passo a passo.

1. Verifica o Estado Atual do AppArmor

Começa por instalar as ferramentas de administração e auditar o teu sistema:

# Instala os utilitários de gestão do AppArmor e o serviço de auditoria
apt update && apt install -y apparmor apparmor-utils auditd

# Inspeciona os perfis ativos na tua máquina
aa-status

O comando mostra-te quantos perfis estão em modo enforce (a bloquear) e quantos estão em modo complain (apenas a monitorizar), listando ainda os processos ativos sem qualquer proteção.

2. Cria o Perfil de Segurança para o Nginx

Cria um novo ficheiro de perfil no caminho /etc/apparmor.d/usr.sbin.nginx:

#include <tunables/global>

profile nginx /usr/sbin/nginx {
  #include <abstractions/base>
  #include <abstractions/nameservice>
  #include <abstractions/ssl_certs>

  # Permissões de rede para escuta web
  network inet stream,
  network inet6 stream,

  # Binários e ficheiros de configuração do Nginx
  /usr/sbin/nginx mr,
  /etc/nginx/** r,
  /run/nginx.pid rw,

  # Ficheiros de registo e logs
  /var/log/nginx/* w,
  /var/log/nginx/*.log w,

  # Acesso aos ficheiros do site (Apenas Leitura)
  /var/www/** r,

  # Buffers temporários para uploads de clientes
  /var/lib/nginx/body/* rw,
  /var/lib/nginx/fastcgi/* rw,
  /var/lib/nginx/proxy/* rw,

  # BLOQUEIO EXPRESSO de consolas e scripts executáveis
  deny /bin/** x,
  deny /usr/bin/** x,
  deny /tmp/** rw,
  deny /var/tmp/** rw,
}

FRONTEIRAS DE ISOLAMENTO DO TEU PERFIL

• ACESSO PERMITIDO
• ACESSO TERMINANTEMENTE PROIBIDO
• /etc/nginx/ (Ler configurações): /var/www/ (Ler ficheiros web) • /run/nginx.pid (Gestão do processo) • /var/log/nginx/* (Gravação de logs)
• /bin/ (Nenhuma shell ou sh): /tmp/ (Sem ficheiros executáveis) • /etc/shadow, ficheiros de sistema • Sockets não autorizados de rede

Analisa a robustez desta configuração: mesmo que um invasor explore uma falha num plugin ou cabeçalho HTTP, o Nginx está completamente impedido de lançar ferramentas da pasta /bin ou de criar ficheiros na diretoria /tmp. Seguindo as recomendações da OWASP, cortas pela raiz qualquer hipótese de movimentação lateral no servidor.

Treinar o Perfil: Como Usar o Modo Complain e o aa-logprof

Nunca coloques um perfil diretamente em modo de bloqueio num servidor de produção sem o testares previamente. Arriscas-te a partir uploads de ficheiros, tarefas agendadas ou rotas dinâmicas da tua aplicação. O método profissional consiste em treinar a aplicação no modo complain.

CICLO DE VIDA DE UM PERFIL APPARMOR

• 1. Escrever o Perfil: Definir caminhos básicos e permissões
• 2. Ativar aa-complain: Permite acessos mas regista infrações no log
• 3. Tráfego Real: Executar testes, submeter formulários, compras
• 4. Executar aa-logprof: Ferramenta interativa analisa os registos
• 5. Ativar aa-enforce: Trancar a aplicação em modo de defesa máxima

1. Coloca o Perfil em Modo de Escuta

Ativa o modo de reclamação para o binário do Nginx:

# Configura o Nginx para modo de monitorização
aa-complain /usr/sbin/nginx

# Recarrega o motor de segurança no kernel e reinicia o serviço
systemctl reload apparmor
systemctl restart nginx

Agora, usa o teu site normalmente: navega nas páginas, simula pagamentos, faz upload de ficheiros de teste e recarrega os teus serviços. Se o Nginx tentar aceder a um caminho que não previste, o kernel deixa passar o pedido mas grava o evento em /var/log/audit/audit.log.

2. Afina as Regras com o aa-logprof

Depois de simulares a utilização real do sistema, executa o assistente:

# Analisa os logs de auditoria e ajusta o perfil de forma interativa
aa-logprof

A ferramenta mostra-te cada caminho que foi solicitado durante os teus testes e pergunta se queres permitir ou negar esse acesso. Quando terminares, grava o ficheiro e passa o serviço para o modo de proteção estrita:

# Aplica a proteção em modo de bloqueio definitivo
aa-enforce /usr/sbin/nginx
aa-status

Deteção de Intrusões: Como Identificar Tentativas de Invasão nos Logs

Quando o AppArmor bloqueia um ataque real no teu servidor, como é que tu e a tua equipa se apercebem do incidente? O sistema transmite todos os bloqueios através do subsistema de auditoria do Linux.

Consulta os Bloqueios em Tempo Real

Podes pesquisar diretamente os bloqueios recentes na consola:

# Procura eventos de segurança intercetados pelo auditd
ausearch -m AVC,USER_AVC -ts recent

# Ou inspeciona as mensagens do kernel com dmesg
dmesg -T | grep -i "apparmor=\"DENIED\""

Se um cibercriminoso tentar forçar a execução de uma shell através do Nginx, vais ver uma linha como esta:

[Sun Oct 19 14:22:01 2026] audit: type=1400 audit(1729347721.412:89): apparmor="DENIED" 
operation="exec" class="file" profile="nginx" name="/bin/dash" pid=482109 
comm="nginx" requested_mask="x" denied_mask="x" fsuid=33 ouid=0

Repara nos dados técnicos do alerta:

• operation="exec": O processo tentou executar um programa no servidor.
• profile="nginx": O bloqueio foi efetuado pelo perfil que configuraste para o Nginx.
• name="/bin/dash": O invasor tentou invocar uma consola de comandos.
• denied_mask="x": O kernel rejeitou a permissão de execução.
• fsuid=33: O processo estava a correr sob o utilizador www-data.

Como o kernel bloqueou a operação pela raiz, o invasor não conseguiu instalar nada nem comunicar com o exterior. Combinando este confinamento nativo com os princípios de anti-over-engineering, garantes que a tua máquina em Debian fica blindada sem precisares de soluções complexas que tornam a infraestrutura lenta e pesada.

No terreno, em conjunto com a experiência acumulada na Webxtek Studio, aplicamos exatamente estes padrões operacionais em setores exigentes como cibersegurança e especialistas em devops e arquitetura cloud. Quando alinhas a tua estrutura através de alojamento gerido para websites e aplicações e consultoria técnica antes de construir, transformas boas práticas técnicas numa vantagem competitiva real e mensurável para o teu negócio.