Processos Privilegiados

1. Definição e Contexto

A execução de Processos Privilegiados na Atribuição de Portas é uma das defesas fundamentais implementadas diretamente no núcleo (Kernel) de sistemas operacionais modernos Unix-like. Existe uma fronteira técnica histórica e intransponível que separa serviços críticos de infraestrutura (SSH, SMTP, Web, DNS) dos programas de usuários comuns. Esta restrição, que impede que qualquer processo sem autoridade administrativa absoluta abra soquetes em portas baixas, garante que o "comando central" da rede não seja sequestrado por usuários locais maliciosos ou processos comprometidos que buscam personificar serviços do sistema.

Características Fundamentais

• Fronteira: Portas 0-1023 (well-known) requerem UID 0 (root).
• Mecanismo: Syscall bind() valida UID do processo solicitante.
• Origem: BSD Unix original (anos 1980), preservado em Linux moderno.
• RFC de referência: RFC 6056 (Port Randomization) e POSIX.1-2017 (Sockets).
• Mitigação moderna: Linux Capabilities (CAP_NET_BIND_SERVICE), seccomp, namespaces.

2. A Fronteira Root das Portas Well-Known (< 1024)

O Kernel de um sistema operacional profissional impõe uma regra de segurança nativa sobre o primeiro bloco de portas lógicas (0 a 1023):

O Mecanismo da Chamada bind()

Quando o código de um programa solicita ao Kernel para "reservar" (bind()) uma porta padronizada (ex.: porta 22 para SSH, 80 para HTTP), o sistema operacional realiza uma auditoria imediata do UID (User Identifier) do processo solicitante. Se o UID não for 0 (root), a função falha e o programa recebe o erro EACCES (Permission Denied).

Fluxo da Syscall bind()

bind(fd, struct sockaddr_in *addr, len)
  → kernel: addr->sin_port == 22?
  → sim: kernel: current_uid() == 0?
       → sim: bind OK
       → não: return -EACCES
  → não: bind OK (qualquer usuário pode bind em portas altas)

Prevenção de Spoofing Local

Sem esta restrição, qualquer desenvolvedor ou processo infectado poderia subir um servidor DNS falso na porta 53 ou um site de phishing na porta 80 do próprio host, capturando credenciais de outros usuários que acessassem apontamentos locais (localhost:80).

3. Distribuição de Portas por Privilégio

Portas Efêmeras (RFC 6056)

Quando um cliente abre conexão para servidor, o Kernel atribui automaticamente uma porta efêmera. Em Linux moderno, o intervalo é 32768-60999 (configurável via net.ipv4.ip_local_port_range).

4. Mitigação Moderna: Linux Capabilities

Manter uma aplicação complexa rodando continuamente como root apenas para garantir o acesso a uma porta é uma falha de segurança arquitetural grave.

CAP_NET_BIND_SERVICE

Versões modernas do Kernel Linux (desde 2.6.24, 2008) introduziram o conceito de Linux Capabilities — divisão dos privilégios de root em unidades granulares. A capability CAP_NET_BIND_SERVICE permite que um binário específico faça bind() em portas < 1024, sem precisar de outros privilégios de root.

Operações com Capabilities

# Atribuir capability a um binário (executado por usuário comum)
sudo setcap 'cap_net_bind_service=+ep' /usr/bin/python3

# Verificar capabilities de um binário
getcap /usr/bin/python3

# Listar todas as capabilities disponíveis
capsh --print

# Remover capability
sudo setcap -r /usr/bin/python3

Capacities Mais Relevantes para Rede

5. Estratégia de Drop Privileges

Servidores de elite como Nginx, Apache e Postfix utilizam uma técnica de dois estágios:

1. Master process: Inicia como root, faz bind() em portas 80/443.
2. Fork workers: Cria processos filhos que abandonam privilégios via setuid() para usuários sem root (www-data, nginx).
3. Operação: Todas as requisições são tratadas pelos workers sem root.

Exemplo: Nginx

user www-data;
worker_processes auto;
pid /run/nginx.pid;

events {
    worker_connections 768;
}

http {
    # O master (root) faz bind nas portas 80/443
    # Os workers (www-data) tratam requisições
    server {
        listen 80;
        listen 443 ssl;
        # ...
    }
}

Vantagem

Se um atacante descobrir um exploit de buffer overflow no servidor web, terá apenas o acesso do usuário www-data — sem acesso a /etc/shadow, sem controle de rede (faltam CAP_NET_ADMIN, CAP_NET_RAW).

6. Tuning de Kernel (Sysctl)

net.ipv4.ip_unprivileged_port_start

sysctl net.ipv4.ip_unprivileged_port_start          # ver (default 1024)
sudo sysctl -w net.ipv4.ip_unprivileged_port_start=80  # permitir comuns em 80+
echo 'net.ipv4.ip_unprivileged_port_start=80' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Risco: aumenta conveniência para desenvolvedores, mas cria risco de personificação de serviços. Em contêineres Docker, este sysctl é 0 por padrão (qualquer porta acessível). Em máquinas sem root, usa-se authbind, intermediário de confiança que permite abrir soquetes em portas Well-Known sem comprometer a identidade do sistema (configuração em /etc/authbind/byport/).

7. Auditoria de Binários SUID/SGID

Atacantes buscam binários de sistema que possuam o bit SUID ativado. Se um script de automação de rede inseguro rodar como root para abrir um socket administrativo, um invasor pode manipular variáveis de ambiente para sequestrar o processo e ganhar shell root.

Identificação de Binários SUID Perigosos

# Listar todos os binários SUID no sistema
sudo find / -perm /4000 -type f 2>/dev/null

# Listar SGID
sudo find / -perm /2000 -type f 2>/dev/null

# Verificar permissões de binários de rede sensíveis
ls -l /usr/bin/ping /usr/bin/traceroute /usr/sbin/tcpdump

8. Containers e Isolamento de Privilégios

Em Docker/Podman, o "root dentro do container" mapeia para UID não-privilegiado no host (user namespace). Combinado com capabilities mínimas, limita dano mesmo em caso de escape.

FROM nginx:alpine
USER nginx
EXPOSE 8080   # porta alta, evita bind root

Boas práticas: USER nonroot no Dockerfile; --cap-drop ALL + --cap-add NET_BIND_SERVICE; --read-only e --security-opt no-new-privileges.

9. Auditoria e Diagnóstico

# Verificar quem escuta em portas baixas (deve ser root ou via capability)
sudo ss -tulpn | awk '$5 ~ /:(\d{1,3})\s/ && $5 !~ /:(\d{4,5})/'

# Confirmar UID dono de um processo específico
ps -o pid,user,uid,comm -p $(sudo lsof -t -i :22)

# Listar capabilities de um binário
getcap /usr/sbin/nginx

# Verificar falhas de bind negadas (logs do kernel)
sudo dmesg | grep -i "bind\|permission"

# Auditar sysctl relacionado
sysctl net.ipv4.ip_unprivileged_port_start net.ipv4.ip_local_port_range

10. Resumo Técnico

11. Conclusão

Os Processos Privilegiados são as sentinelas que guardam a entrada da inteligência da rede. Do controle rigoroso sobre quem pode abrir portas de sistema, somado a arquitetura sólida de separação de privilégios (drop privileges), capabilities granulares e isolamento por containers, depende a integridade e a privacidade de todo o ambiente. Para administradores e analistas de segurança, dominar a lógica das capabilities do Linux, auditar binários SUID e configurar corretamente sysctls de rede são tarefas essenciais de hardening que reduzem drasticamente o raio de ação de invasores.