Gerador de Snippet Allow/Deny CIDR (nginx)

O Gerador de Trecho Permissão/Negação CIDR para nginx cria blocos de configuração nginx prontos para uso com diretivas allow e deny a partir de listas de endereços IP ou blocos CIDR. Digite endereços como 192.168.1.0/24 e 10.0.0.0/8, escolha modo allowlist ou blocklist e obtenha diretivas corretamente formatadas que você pode colar diretamente em seus blocos de servidor ou salvar como um arquivo de inclusão.

Entendendo Controle de Acesso nginx

Se você executa nginx como servidor web ou proxy reverso, controle de acesso baseado em IP é uma das formas mais simples e efetivas de proteger recursos sensíveis. O ngx_http_access_module é compilado no nginx por padrão e não requer nenhuma instalação adicional -- você apenas adiciona diretivas allow e deny à sua configuração. Esta é a abordagem padrão para restringir painéis de admin, APIs internas, servidores de preparação e qualquer endpoint que não deveria estar acessível publicamente.

O conceito é direto: você lista os endereços IP ou blocos CIDR que deveriam ser permitidos (ou negados) e nginx verifica cada solicitação recebida contra a lista. O detalhe chave que pega as pessoas é ordem de avaliação. Nginx processa diretivas allow e deny de cima para baixo e para na primeira correspondência. Se deny all aparece antes de suas linhas allow, cada solicitação é negada independentemente do IP de origem. O gerador lida com isso automaticamente ao sempre colocar a regra padrão no fim, mas entender o modelo de avaliação é importante quando você está resolvendo problemas de acesso.

Onde controle de acesso nginx fica complicado é em configurações multi-nível. Diretivas em um bloco location sobrescrevem aquelas no bloco server de envoltório, que sobrescrevem aquelas no bloco http. Se você configura uma allowlist em seu bloco de servidor mas esquece de aplicá-la a uma localização específica, aquela localização herda o que o pai define. Para configurações complexas, a abordagem mais limpa é colocar suas regras de acesso em um arquivo separado e incluí-lo onde for necessário, que é exatamente o fluxo de trabalho que o gerador suporta.

Como Gerar Diretivas Allow/Deny nginx

1. Digite seus endereços IP ou blocos CIDR -- um por linha ou separados por vírgula.
2. Selecione o modo: allowlist (permita IPs listados, negar todos os outros) ou blocklist (negar IPs listados, permitir todos os outros).
3. O gerador formata cada entrada como uma diretiva nginx apropriada com sintaxe correta.
4. Copie a saída para seu bloco nginx server, location ou http, ou salve como arquivo de inclusão.
5. Execute nginx -t para testar a configuração, depois recarregue com nginx -s reload.

Exemplos de Saída Allow/Deny nginx

Modo Allowlist

Entrada:

192.168.1.0/24
10.0.0.0/8
203.0.113.50

Saída:

allow 192.168.1.0/24;
allow 10.0.0.0/8;
allow 203.0.113.50;
deny all;

Modo Blocklist

Entrada:

198.51.100.0/24
203.0.113.0/24

Saída:

deny 198.51.100.0/24;
deny 203.0.113.0/24;
allow all;

Usando um Arquivo de Inclusão

server {
    listen 443 ssl;
    server_name admin.example.com;

    include /etc/nginx/conf.d/admin-allowlist.conf;

    location / {
        proxy_pass http://backend;
    }
}

Quando Usar o Gerador de Trecho CIDR nginx

• Proteção de painel de admin -- Restrinja acesso /admin ou /wp-admin apenas para intervalos de IP de escritório e VPN.
• Controle de acesso do servidor de preparação -- Limite ambientes de preparação para endereços IP de equipe de desenvolvedor e QA.
• Limitação de taxa de API por IP -- Combinado com limit_req_zone, permita limites mais altos para IPs de parceiros conhecidos enquanto restringe fontes desconhecidas.
• Bloqueio geográfico -- Bloqueie intervalos CIDR inteiros no nível de país a partir de acesso a recursos específicos.
• Requisitos de conformidade -- Restrinja acesso a endpoints de dados sensíveis apenas para intervalos de rede corporativa aprovados.

Como Funcionam as Diretivas de Controle de Acesso nginx

Ordem de Processamento de Regra

Nginx avalia diretivas allow e deny em ordem de cima para baixo. A primeira regra correspondente vence. Isto significa:

# Isto FUNCIONA -- allow específico antes de deny geral
allow 192.168.1.0/24;
deny all;

# Isto NÃO FUNCIONA -- deny all é avaliado primeiro
deny all;
allow 192.168.1.0/24;   # nunca alcançado

O gerador sempre coloca a regra padrão (deny all ou allow all) no fim para garantir avaliação correta.

Escopo de Diretiva

Diretivas de controle de acesso podem ser colocadas em diferentes níveis:

• bloco http -- Aplica-se a todos os hosts virtuais
• bloco server -- Aplica-se a um host virtual específico
• bloco location -- Aplica-se a um caminho de URL específico

location /api/internal {
    allow 10.0.0.0/8;
    deny all;

    proxy_pass http://internal-api;
}

Suporte IPv6

O gerador lida com endereços e blocos CIDR IPv6 com a mesma sintaxe:

allow 2001:db8::/32;
allow 192.168.1.0/24;
deny all;

Combinação com Cabeçalhos de Proxy

Quando nginx está atrás de um balanceador de carga ou CDN, o IP do cliente vem de um cabeçalho como X-Forwarded-For em vez da conexão TCP. Neste caso, use o ngx_http_realip_module para definir o IP do cliente real antes da avaliação de controle de acesso:

set_real_ip_from 10.0.0.0/8;       # confie no intervalo de seu balanceador de carga
real_ip_header X-Forwarded-For;
real_ip_recursive on;

allow 203.0.113.0/24;              # permita com base em IP do cliente real
deny all;

Conselhos Práticos para Controle de Acesso nginx

O erro mais comum com controle de acesso nginx é não testar sua configuração antes de recarregar. Um ponto-e-vírgula faltante, um bloco CIDR inválido ou até um caractere solto causará nginx -t falhar e, se você recarregar sem testar, a configuração antiga permanece ativa -- mas da próxima vez que nginx reinicia (após reboot do servidor, por exemplo), ele recusará iniciar completamente porque a configuração inválida está no disco. Sempre execute nginx -t antes de nginx -s reload e considere colocar esta verificação em seus scripts de implantação como um portão automatizado.

Ao proteger painéis de admin, não confie apenas em controle de acesso baseado em IP. Use-a como uma camada em uma abordagem de defesa em profundidade: allowlist de IP para limitar quem pode até chegar à página de login, autenticação forte atrás dela e limitação de taxa para impedir ataques de força bruta de qualquer IP permitido. Endereços IP podem ser falsificados na camada de aplicação (via cabeçalhos forjados), então certifique-se de que configurou real_ip_header corretamente se estiver atrás de um proxy reverso e nunca confie em X-Forwarded-For diretamente sem validar o upstream imediato.

Para allowlists grandes (centenas de entradas), considere usar o módulo geo em vez de diretivas allow/deny individuais. O módulo geo usa uma árvore de busca binária internamente, que é mais rápido que o scan linear de allow/deny para listas grandes. O trade-off é configuração ligeiramente mais complexa, mas para listas além de 50-100 entradas, a diferença de desempenho é mensurável em servidores de alto tráfego.

Perguntas Frequentes

Por que nginx falha ao iniciar depois de adicionar regras allow/deny? A causa mais comum é um ponto-e-vírgula faltante no fim de uma linha de diretiva. Toda linha allow e deny deve terminar com ;. O gerador lida com isto automaticamente. Execute nginx -t para verificar sintaxe antes de recarregar.

Posso misturar diretivas allow e deny em um único bloco? Sim, mas a ordem importa. Nginx processa regras de cima para baixo e para na primeira correspondência. Tipicamente você ou permite um conjunto de IPs e nega todos os outros, ou nega um conjunto e permite todos os outros. Misturar allow e deny para intervalos de IP diferentes no mesmo bloco é válido mas mais difícil de manter.

Qual é a diferença entre deny all e return 403? deny all é uma diretiva de controle de acesso que retorna uma resposta 403 Forbidden. return 403 é uma diretiva de conteúdo que também retorna 403 mas não participa da cadeia de avaliação allow/deny. Para controle de acesso baseado em IP, sempre use diretivas allow/deny.

Como incluo o trecho gerado em minha configuração nginx? Salve a saída em um arquivo como /etc/nginx/conf.d/allowlist.conf e use a diretiva include em seu bloco de servidor ou localização: include /etc/nginx/conf.d/allowlist.conf;

E se meu nginx estiver atrás de um CDN ou balanceador de carga? Você precisa configurar o ngx_http_realip_module para extrair o IP do cliente real do cabeçalho apropriado (geralmente X-Forwarded-For ou X-Real-IP). Sem isto, nginx vê o IP do CDN ou balanceador de carga para cada solicitação e sua allowlist corresponde contra o endereço errado.

Há um limite para quantas regras allow/deny nginx pode lidar? Não há limite absoluto, mas desempenho se degrada linearmente com o número de regras porque nginx as escaneia sequencialmente. Para listas além de 100 entradas, considere usar o módulo geo ou diretiva map para melhor desempenho. Para a maioria das configurações com menos de 50 regras, o impacto de desempenho é negligenciável.

Ferramentas Relacionadas

• Gerador de Trecho Require ip Apache - Gere diretivas Apache Require ip
• Construtor de Allowlist - Construa allowlist CIDR mínimo a partir de lista de IP
• Construtor de Blocklist - Construa blocklist CIDR mínimo a partir de lista de IP
• Gerador de Regra iptables - Gere regras iptables a partir de CSV
• Validador de Allowlist IP:Porta - Valide entradas em massa IP:porta