Segurança Essencial do Nginx: Melhores Práticas e Perguntas Frequentes de Solução de Problemas

A segurança essencial do Nginx não é uma configuração única ou um cabeçalho mágico. É uma coleção de padrões cuidadosos: HTTPS, acesso restrito a arquivos, comportamento seguro de proxy, exposição limitada e logs que ajudam a identificar problemas antes que eles cresçam.

Esta FAQ cobre as perguntas que as equipes geralmente fazem depois de colocar o Nginx online e perceber que a configuração padrão é apenas um ponto de partida.

Quais São as Primeiras Configurações de Segurança do Nginx a Revisar?

Comece com o básico que reduz a exposição acidental. Essas configurações protegem contra erros comuns, não contra ataques avançados.

Primeiro, desative os tokens de versão:

server_tokens off;

Isso impede que o Nginx anuncie sua versão em páginas de erro e cabeçalhos. Não torna o servidor invisível, mas remove detalhes desnecessários.

Segundo, certifique-se de que a raiz do documento está correta. Um erro comum é apontar root para um diretório do projeto em vez do diretório de build público. Isso pode expor arquivos fonte, exemplos de ambiente ou ativos privados.

Para um site estático, prefira algo como:

root /var/www/example.com/public;

não:

root /var/www/example.com;

Terceiro, bloqueie arquivos ocultos, a menos que sua aplicação realmente precise deles:

location ~ /\.(?!well-known) {
    deny all;
}

Isso permite caminhos .well-known usados para validação de certificados, enquanto nega arquivos como .env, .git e .htpasswd.

Finalmente, revise os limites de upload. Se seu site não aceita uploads grandes, mantenha client_max_body_size modesto. Isso reduz o raio de explosão de requisições grandes acidentais.

Como o Nginx Deve Lidar com HTTPS?

HTTPS deve ser o caminho normal para sites públicos e APIs. Redirecione HTTP simples para HTTPS, use certificados válidos e evite configurações de protocolo desatualizadas.

Um bloco de servidor de redirecionamento simples se parece com isso:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

O bloco de servidor HTTPS deve referenciar seus arquivos de certificado e incluir configurações modernas de TLS. Muitas equipes usam Certbot ou um balanceador de carga gerenciado para lidar com certificados. O ponto importante é manter a renovação automatizada e monitorada.

Cabeçalhos de segurança também podem ajudar os navegadores a tomar decisões mais seguras:

add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

Tenha cuidado com a Política de Segurança de Conteúdo (Content Security Policy). Ela é poderosa, mas uma política rigorosa pode quebrar scripts, fontes, análises ou conteúdo incorporado se aplicada sem teste. Comece no modo apenas relatório quando possível.

Para um passo a passo prático sobre HTTPS, veja protegendo Nginx com HTTPS.

Como Proteger o Nginx como Proxy Reverso?

Quando o Nginx faz proxy de tráfego para um aplicativo, você precisa preservar as informações corretas da requisição sem confiar cegamente na entrada do cliente.

Cabeçalhos de proxy comuns se parecem com isso:

proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;

Esses cabeçalhos ajudam a aplicação upstream a entender a requisição original. Eles são úteis para logging, redirecionamentos, limitação de taxa e verificações de segurança.

Se o Nginx estiver atrás de outro proxy confiável ou balanceador de carga, configure o tratamento de IP real cuidadosamente. Confie apenas em endereços de proxy conhecidos:

set_real_ip_from 10.0.0.0/8;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

Não confie em X-Forwarded-For vindo da internet aberta. Um cliente pode forjar esse cabeçalho. Confie nele apenas quando a requisição vier do seu balanceador de carga, CDN ou proxy interno.

Você também deve ocultar detalhes de implementação do upstream. Se seu aplicativo retorna cabeçalhos específicos do framework que você não precisa, remova-os na camada de proxy ou aplicação.

Devo Usar Limitação de Taxa?

A limitação de taxa é útil para páginas de login, endpoints de busca, APIs caras e qualquer rota que atacantes possam abusar de forma barata. Não substitui a segurança da aplicação, mas pode desacelerar tentativas de força bruta e tráfego ruidoso.

Exemplo:

limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

server {
    location /login {
        limit_req zone=login burst=10 nodelay;
        proxy_pass http://app_backend;
    }
}

Isso cria uma zona de memória compartilhada chaveada pelo IP do cliente e limita requisições ao caminho de login. Os valores exatos dependem dos seus usuários. Um painel corporativo geralmente pode tolerar limites mais rigorosos do que um aplicativo público de consumo em redes móveis.

Teste os limites de taxa cuidadosamente. Se seu site estiver atrás de um proxy e você não configurou o tratamento de IP real do cliente, todos os usuários podem parecer vir do mesmo endereço. Isso pode bloquear tráfego legítimo.

Por Que Ainda Estou Vendo Requisições Suspeitas?

Servidores Nginx públicos recebem ruído de fundo constante: varreduras por painéis admin antigos, arquivos PHP, caminhos WordPress e arquivos de ambiente expostos. Ver essas requisições nos logs nem sempre significa que você foi comprometido.

O que importa é como seu servidor responde. Uma requisição para /wp-admin em um site não-WordPress deve retornar 404 ou 403. Uma requisição para /.env nunca deve retornar segredos. Uma requisição com um caminho estranho não deve ser encaminhada para um serviço admin interno.

Revise seus logs de acesso para:

• Respostas repetidas 401 ou 403
• Muitas requisições de um IP
• Corpos de requisição grandes
• Sondagem por arquivos ocultos
• User agents incomuns
• Picos em respostas 499, 502 ou 504

Para solução de problemas mais ampla, veja Erros comuns do Nginx.

Quando Pedir Ajuda de Segurança

Traga um engenheiro de segurança ou consultor DevOps experiente quando o Nginx proteger dados de clientes, autenticação, fluxos de pagamento, APIs privadas ou ferramentas admin internas. Você também deve pedir ajuda após qualquer suspeita de violação, exposição inesperada de arquivos ou tráfego de ataque repetido que afete a disponibilidade.

A revisão profissional vale a pena quando a configuração abrange várias camadas, como CDN, balanceador de carga, Nginx, malha de serviço e framework de aplicação. Um arquivo Nginx seguro ainda pode ser enfraquecido por um limite de confiança ruim em outro lugar.

Proteja o Nginx removendo exposição desnecessária, forçando HTTPS, tratando cabeçalhos de proxy com cuidado e monitorando logs. Você não precisa de uma configuração enorme para ser mais seguro. Precisa de padrões claros, mudanças testadas e o hábito de verificar o que seu servidor realmente serve.