Gerador de Trecho Apache Require ip

The Apache Require ip Snippet Generator cria diretivas de controle de acesso Apache 2.4+ corretamente formatadas 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 de lista de permissão ou bloqueio e obtenha blocos <RequireAny> ou <RequireAll> completos com sintaxe Require ip correta pronta para colar em arquivos .htaccess, blocos <Directory> ou diretivas <Location>.

Entendendo Controle de Acesso Apache 2.4

Apache 2.4 introduziu um sistema completamente novo de controle de acesso que substituiu as diretivas Allow/Deny/Order usadas em Apache 2.2 e anteriores. Se você ainda está escrevendo Order deny,allow ou Allow from 192.168.1.0/24, você está usando sintaxe descontinuada que parará de funcionar quando seu servidor for atualizado. A abordagem moderna usa diretivas Require embrulhadas em tags de container como <RequireAny> e <RequireAll> e a lógica é mais explícita e menos propensa a erro uma vez que você a entende.

O sistema antigo Apache 2.2 era notoriamente confuso. A diretiva Order determinava qual conjunto de regras era avaliado primeiro e a interação entre Allow e Deny levou a inúmeros servidores mal configurados. Order deny,allow significava "negar por padrão, depois aplicar regras de Allow" - mas se você acidentalmente escreveu Order allow,deny, o comportamento se inverteu e seu diretório supostamente restrito se tornou aberto. Apache 2.4 elimina esta ambigüidade com diretivas de container que deixam a lógica explícita: <RequireAny> significa "permitir se qualquer condição corresponder" (lógica OR) e <RequireAll> significa "permitir apenas se todas as condições corresponderem" (lógica AND).

Este gerador economiza tempo e previne erros de sintaxe ao produzir blocos de controle de acesso Apache 2.4 corretamente estruturados. Trata das tags de container, formatação apropriada de Require ip e o uso correto de Require not ip para modo de bloqueio. Se você está migrando de Apache 2.2, atualizando de nginx ou construindo controles de acesso novos do zero, o gerador fornece configuração pronta para implantação que você pode colar diretamente em seus arquivos de configuração Apache.

Como Gerar Diretivas Apache Require ip

1. Digite seus endereços IP ou blocos CIDR - um por linha ou separados por vírgula
2. Selecione o modo: lista de permissão (permitir IPs listados, negar todos os outros) ou lista de bloqueio (negar IPs listados, permitir todos os outros)
3. O gerador produz um bloco de diretiva Apache completo com estrutura de container apropriada
4. Copie a saída em seu arquivo .htaccess, bloco <Directory> ou bloco <Location>
5. Reinicie Apache ou recarregue a configuração para aplicar as mudanças

Exemplos de Saída de Controle de Acesso Apache 2.4

Modo de Lista de Permissão

Entrada:

192.168.1.0/24
10.0.0.0/8
203.0.113.50

Saída:

<RequireAny>
    Require ip 192.168.1.0/24
    Require ip 10.0.0.0/8
    Require ip 203.0.113.50
</RequireAny>

Modo de Lista de Bloqueio

Entrada:

198.51.100.0/24
203.0.113.0/24

Saída:

<RequireAll>
    Require all granted
    Require not ip 198.51.100.0/24
    Require not ip 203.0.113.0/24
</RequireAll>

Uso em Bloco de Diretório

<Directory "/var/www/html/admin">
    <RequireAny>
        Require ip 192.168.1.0/24
        Require ip 10.10.0.0/16
    </RequireAny>
</Directory>

Comparação de Sintaxe Apache 2.2 vs. Apache 2.4

Quando Usar o Apache Require ip Generator

• Migração Apache 2.2 para 2.4 - Converta regras Allow/Deny legadas em sintaxe moderna Require ip durante atualizações de servidor
• Proteção de diretório de admin - Restrinja acesso a /admin, /phpmyadmin ou /server-status apenas a IPs confiáveis
• Migração cross-platform - Converta regras nginx allow/deny ou regras iptables para formato Apache ao mudar servidores web
• Implantação .htaccess - Gere regras de acesso para configurações distribuídas onde arquivos .htaccess controlam acesso por diretório
• Configs multi-ambiente - Crie arquivos de inclusão separados para listas de permissão IP de desenvolvimento, staging e produção

Como Funciona o Controle de Acesso Apache 2.4

RequireAny vs. RequireAll

Apache 2.4 usa diretivas de container para controlar a relação lógica entre regras de acesso:

• <RequireAny> - Acesso é concedido se qualquer diretiva encerrada corresponde (lógica OR). Usado para listas de permissão onde qualquer IP listado deve ser permitido
• <RequireAll> - Acesso é concedido apenas se todas as diretivas encerradas correspondem (lógica AND). Usado para listas de bloqueio onde tráfego deve passar todas as condições
• <RequireNone> - Acesso é negado se qualquer diretiva encerrada corresponde. Útil dentro de <RequireAll> para exceções

Placement de Diretiva

Diretivas de controle de acesso funcionam em vários contextos:

# Em httpd.conf ou config de vhost
<Location "/api/internal">
    <RequireAny>
        Require ip 10.0.0.0/8
    </RequireAny>
</Location>

# Em .htaccess (se AllowOverride AuthConfig está definido)
<RequireAny>
    Require ip 192.168.1.0/24
</RequireAny>

Erro Comum: Container Faltando

Uma diretiva Require ip desprotegida sem um container funciona mas se comporta diferentemente quando combinada com outras diretivas de auth. Sempre embrulhe regras de acesso em <RequireAny> ou <RequireAll> para comportamento previsível:

# Frágil - pode conflitar com outros módulos de auth
Require ip 192.168.1.0/24

# Robusto - explicitamente define lógica de avaliação
<RequireAny>
    Require ip 192.168.1.0/24
</RequireAny>

Combinando Autenticação IP e de Usuário

Um dos padrões mais comuns é permitir acesso seja de um intervalo IP confiável ou com credenciais válidas:

<RequireAny>
    Require ip 10.0.0.0/8
    Require valid-user
</RequireAny>

Isto significa que usuários na rede interna entram automaticamente enquanto usuários externos devem fazer login. O container <RequireAny> deixa esta lógica OR explícita.

Conselho Prático para Controle de Acesso Apache

A fonte mais frequente de confusão ao migrar para Apache 2.4 é que ambas a sintaxe antiga e nova podem parecer funcionar simultaneamente se o módulo mod_access_compat é carregado. Este módulo fornece compatibilidade para trás para diretivas Allow/Deny/Order, então sua configuração antiga continua funcionando após uma atualização - mas misturar sintaxe antiga e nova no mesmo bloco <Directory> cria comportamento imprevisível. Ao migrar, ou converta tudo de uma vez ou certifique-se que sintaxe antiga e nova nunca aparecem no mesmo escopo. O gerador produz apenas sintaxe Apache 2.4, então verifique que mod_access_compat não está interferindo antes de implantar.

Para implantações .htaccess, lembre-se que a configuração de servidor deve explicitamente permitir sobreposições de controle de acesso. A diretiva AllowOverride na configuração principal deve incluir AuthConfig (ou All) para o diretório em questão. Se AllowOverride None está definido, Apache silenciosamente ignora todas as diretivas .htaccess, incluindo suas cuidadosamente elaboradas regras Require ip. Este é um gotcha comum em hosting compartilhado onde o administrador do servidor controla AllowOverride.

Ao proteger diretórios sensíveis como /phpmyadmin ou /server-status, considere combinar restrições IP com autenticação. Controle de acesso apenas baseado em IP é vulnerável a falsificação de IP na camada de aplicação (headers X-Forwarded-For forjados) se Apache está atrás de um proxy reverso. Defina RemoteIPHeader e RemoteIPTrustedProxy corretamente para prevenir injeção de header e adicione Require valid-user como segundo fator para que até atacantes na sua rede interna precisem de credenciais para acessar ferramentas críticas.

Perguntas Frequentes

Por que recebo erro 500 depois de adicionar diretivas Require ip?

A causa mais comum é usar sintaxe Apache 2.2 (Allow from, Deny from) em um servidor Apache 2.4 ou vice versa. Verifique sua versão Apache com httpd -v ou apache2 -v e use a sintaxe correspondente. O gerador produz exclusivamente sintaxe Apache 2.4+.

Posso combinar autenticação baseada em IP e em usuário?

Sim. Use <RequireAny> para permitir acesso se o usuário está seja em um IP confiável ou tem credenciais válidas:

<RequireAny>
    Require ip 10.0.0.0/8
    Require valid-user
</RequireAny>

Isto funciona com arquivos .htaccess?

Sim, desde que a configuração de servidor AllowOverride inclua AuthConfig. Se AllowOverride None está definido na config de servidor, diretivas .htaccess são ignoradas silenciosamente.

Como sei se meu servidor usa Apache 2.2 ou 2.4?

Execute httpd -v ou apache2 -v na linha de comando. Se a versão começa com 2.4, use a sintaxe Require ip que este gerador produz. Se começa com 2.2, você precisa da sintaxe Allow/Deny antiga - mas você também deveria planejar atualizar já que Apache 2.2 atingiu fim de vida em 2018.

Qual é a diferença entre Require all denied e Require not ip?

Require all denied bloqueia todo tráfego incondicionalmente. Require not ip 10.0.0.0/8 bloqueia tráfego de um intervalo específico enquanto permite tudo mais (quando usado dentro de <RequireAll> com Require all granted). Use Require all denied como fallback para diretórios completamente travados e Require not ip para listas de bloqueio direcionadas.

Posso usar hostnames em vez de endereços IP?

Sim, Apache suporta Require host example.com que executa uma busca DNS reversa. No entanto, isto é mais lento (DNS adiciona latência para cada requisição), menos confiável (DNS pode ser falsificado) e não é recomendado para configurações críticas de segurança. Use endereços IP ou blocos CIDR para controle de acesso.

Ferramentas Relacionadas

• CIDR Allow/Deny Snippet Generator (nginx) - Gere diretivas allow/deny nginx de lista CIDR
• Allowlist Builder - Construa lista de permissão CIDR mínima de lista IP
• Blocklist Builder - Construa lista de bloqueio CIDR mínima de lista IP
• iptables Rule Generator - Gere regras iptables de CSV
• IP:Port Allowlist Validator - Valide entradas bulk IP:port