Melhores Práticas de Segurança do Nginx: Proteja Seu Servidor Web

Seu servidor Nginx é frequentemente o primeiro serviço público que usuários e atacantes podem alcançar. Estas melhores práticas de segurança do Nginx focam nos controles que o Nginx pode realmente aplicar: TLS, limites de requisição, cabeçalhos, regras de acesso, padrões mais seguros e atualizações regulares.

O Nginx não pode corrigir código de aplicação vulnerável por si só. Trate-o como uma camada na frente do seu aplicativo, banco de dados, sistema de autenticação e firewall do host.

Conexões Seguras com TLS

O TLS criptografa o tráfego entre o navegador e seu servidor. Use um certificado confiável, redirecione HTTP para HTTPS e desabilite versões de protocolo obsoletas.

Obter um Certificado

Let's Encrypt é comum para sites públicos, mas qualquer autoridade de certificação confiável pode funcionar. Em muitos servidores Linux, o Certbot armazena arquivos em /etc/letsencrypt/live/seu_dominio.com/.

Configurar HTTPS

Edite o bloco do servidor para seu domínio. O caminho geralmente é /etc/nginx/sites-available/ no Debian/Ubuntu ou /etc/nginx/conf.d/ em sistemas estilo RHEL.

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;

    server_name seu_dominio.com www.seu_dominio.com;

    ssl_certificate /etc/letsencrypt/live/seu_dominio.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/seu_dominio.com/privkey.pem;

    # Inclua suas configurações TLS compartilhadas
    include /etc/nginx/snippets/ssl-params.conf;

    # ... outras configurações (root, blocos de localização, etc.)
}

server {
    listen 80;
    listen [::]:80;
    server_name seu_dominio.com www.seu_dominio.com;

    # Redirecionar HTTP para HTTPS
    return 301 https://$host$request_uri;
}

Usar Parâmetros TLS Conservadores

Você pode manter as configurações TLS compartilhadas em um snippet como /etc/nginx/snippets/ssl-params.conf.

# /etc/nginx/snippets/ssl-params.conf

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;

# Ativar HSTS (HTTP Strict Transport Security)
# Adicione includeSubDomains se aplicável
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

# Ativar OCSP Stapling para verificações de certificado mais rápidas
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;

# Parâmetros Diffie-Hellman (gere um forte se necessário)
# ssl_dhparam /etc/nginx/ssl/dhparams.pem;

ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_session_tickets off;

Adicione includeSubDomains ou preload ao HSTS somente depois de saber que todos os subdomínios suportam HTTPS. Uma implementação ruim do HSTS pode bloquear usuários de subdomínios mais antigos.

Implementar Limitação de Taxa

A limitação de taxa ajuda a desacelerar tentativas de força bruta, raspagem e inundações acidentais de requisições. Não é uma solução completa de DDoS, mas dá mais espaço para seu aplicativo.

Exemplo Básico de Limitação de Taxa

limit_req_zone define o estado compartilhado, e limit_req aplica o limite a uma localização.

http {
    limit_req_zone $binary_remote_addr zone=meulimite:10m rate=5r/s;

    server {
        # ...

        location /login {
            limit_req zone=meulimite burst=10 nodelay;
            # ... sua configuração do manipulador de login
        }

        location / {
            limit_req zone=meulimite burst=20 nodelay;
            # ... sua configuração principal do site
        }
    }
}

Neste exemplo: $binary_remote_addr chaveia o limite pelo endereço IP do cliente. burst=10 permite uma breve rajada acima da taxa média, e nodelay rejeita requisições excessivas em vez de atrasá-las.

Tenha cuidado atrás de um balanceador de carga ou CDN. Se o Nginx vir apenas o endereço IP do proxy, a limitação de taxa por $binary_remote_addr pode punir todos os usuários como um único cliente. Configure o tratamento de IP real confiável antes de confiar em limites por cliente.

Reduzir a Superfície de Ataque Comum

O Nginx pode reduzir a exposição, mas seu aplicativo ainda precisa de validação de entrada, codificação de saída, SQL parametrizado, verificações de autenticação e correção de dependências.

Adicionar Cabeçalhos de Segurança

Cabeçalhos de segurança podem reduzir o risco no lado do navegador:

add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" always;

Uma Política de Segurança de Conteúdo pode ajudar com XSS, mas deve corresponder aos scripts, estilos, imagens e serviços de terceiros do seu aplicativo. Comece em modo apenas relatório antes de aplicá-la em um site de produção.

Bloquear Scanners Óbvios com Cuidado

Bloqueios de padrões simples podem parar scanners barulhentos, mas não substituem um WAF. Mantenha-os estreitos para não bloquear usuários legítimos.

http {
    # Definir um mapa para bloquear bots/scanners ruins
    map $http_user_agent $bad_bot {
        default 0;
        "~*malicious_bot_pattern" 1;
        "~*another_suspicious_agent" 1;
    }

    server {
        # ...
        if ($bad_bot) {
            return 403;
        }
        # ...
    }
}

Restringir Caminhos Sensíveis

Use try_files, mantenha autoindex desligado a menos que precise de listagens de diretórios, e negue acesso a arquivos ocultos que nunca devem ser servidos.

location / {
    root /var/www/html;
    index index.html index.htm;
    try_files $uri $uri/ =404;
    autoindex off; # Desabilitar listagem de diretórios
}

# Exemplo de restrição de acesso a arquivos sensíveis
location ~ /\.ht {
    deny all;
}

Ocultar a Versão do Nginx

server_tokens off remove a versão do Nginx das páginas de erro geradas e reduz detalhes no cabeçalho de resposta Server.

http {
    server_tokens off;
    # ...
}

Limitar Métodos HTTP Onde Apropriado

Se um endpoint aceita apenas GET e POST, rejeite outros métodos lá. Faça isso por localização para não quebrar requisições preflight CORS ou endpoints de API que usam legitimamente PUT, PATCH ou DELETE.

location /api/ {
    # Permitir apenas GET e POST
    if ($request_method !~ ^(GET|POST)$) {
        return 405;
    }
    # ...
}

Manter o Nginx Atualizado

Correções de segurança geralmente chegam através do repositório de pacotes da sua distribuição Linux. Mantenha o Nginx e pacotes relacionados ao OpenSSL corrigidos, e teste recarregamentos após atualizações.

Para Debian/Ubuntu:

sudo apt update
sudo apt upgrade nginx

Para CentOS/RHEL:

sudo dnf update nginx

Use yum update nginx em versões mais antigas do RHEL/CentOS que ainda usam yum.

Adicionar Proteção no Nível do Host

A segurança do Nginx também depende do host ao seu redor:

• Permita apenas portas necessárias em ufw, firewalld, grupos de segurança na nuvem ou ACLs de rede.
• Monitore /var/log/nginx/access.log e /var/log/nginx/error.log para picos, respostas 401/403 repetidas e caminhos suspeitos.
• Use Fail2ban ou uma ferramenta similar quando padrões de log puderem identificar clientes abusivos.
• Execute sudo nginx -t antes de cada recarregamento para que uma mudança de segurança não tire o site do ar.

Conclusão

Comece com HTTPS, atualizações, portas restritas, cabeçalhos seguros e limites de taxa em caminhos sensíveis como /login. Depois, revise seus logs regularmente. A maioria dos ganhos de segurança do Nginx vem de manutenção constante e configuração clara, não de um grande arquivo de endurecimento copiado de outro site.