A DMZ aparece sem uma definição em anexo. Uma linha numa lista de verificação de segurança, uma frase no documento de reforço de um fornecedor, um requisito num anúncio de emprego colocado ao lado de TLS e do menor privilégio.
Procura o termo e encontra o diagrama de uma firewall com três cabos de rede. Um vai para a internet, outro para uma fila de servidores, outro para uma LAN de escritório. O que você administra é um único servidor alugado com um único IP público e nenhuma interface de rede sobressalente.
A primeira imagem é uma verdadeira arquitetura DMZ. Num único servidor, você consegue reproduzir parte do seu objetivo de segurança: limitar o que a internet consegue alcançar. O que não consegue reproduzir nesse mesmo host é a fronteira de rede separada que faz de uma DMZ uma DMZ.
A versão curta
- Uma DMZ separa os serviços que estranhos precisam de alcançar do resto daquilo que você executa.
- A questão nunca foi a cablagem: era garantir que um comprometimento do lado público ficasse por ali.
- Você pode configurar uma firewall e mesmo assim não ter uma DMZ.
- Um único servidor com um único IP público pode reduzir a exposição com um proxy reverso, regras de firewall no host e ligações privadas ou em loopback, mas não cria um segmento DMZ separado.
- Essa versão partilha um kernel com aquilo que protege, por isso conte-a como exposição reduzida e não como isolamento.
O Que Este Artigo Não Aborda
O âmbito aqui é o modelo mental, e três temas adjacentes ficam deliberadamente de fora.
- Sem passos de construção. Não há configuração de proxy reverso, nem sintaxe de regras de firewall, nem recomendação sobre que ferramenta instalar.
- Sem configuração de routers domésticos. A opção "DMZ host" num router de casa designa algo completamente diferente.
- Sem veredicto sobre zero trust. Se o perímetro de rede continua a ser o controlo principal certo é um debate real, e não se resolve aqui.
O que é uma DMZ e para que serve?
Uma DMZ, ou zona desmilitarizada, é um segmento de rede situado entre a internet não confiável e uma rede interna. Aloja os serviços que têm de estar publicamente acessíveis, como servidores web e servidores de correio. Todo o resto fica atrás de uma segunda fronteira, pelo que chegar ao serviço público não significa chegar ao restante.
A entrada do glossário da Mozilla sobre a DMZ resume a metade operativa disso numa única oração: expõe apenas certos endpoints definidos, negando ao mesmo tempo o acesso à rede interna a partir de fora. É esse todo o objetivo de conceção, enunciado sem qualquer referência a equipamento.
Os tipos de serviço que classicamente ali vivem decorrem desse objetivo. Servidores web, servidores de correio, servidores FTP, servidores VoIP: coisas a que se espera que estranhos consigam ligar-se. Servidores de diretório, bases de dados, partilhas de ficheiros, aplicações internas e interfaces administrativas não constam dessa lista, porque ninguém de fora deve sequer alcançá-las.
Fique com a propriedade e não com a imagem. Três interfaces de rede são uma forma de criar uma fronteira de confiança separada. Os desenhos em cloud e de servidor único podem aplicar o mesmo princípio de controlo da exposição de outras maneiras, mas só os que têm uma zona de perímetro distinta reproduzem a própria DMZ.
Como funciona a DMZ clássica de três interfaces?
A DMZ clássica constrói-se de duas maneiras. Um desenho de firewall única dá a essa firewall três interfaces, uma para a internet, uma para a DMZ e uma para a rede interna. Um desenho de firewall dupla coloca a DMZ entre duas firewalls separadas. Ambos impõem a mesma regra. A internet chega à DMZ. A internet nunca chega à rede interna.
O modelo de firewall única (três pernas)
Uma firewall, três interfaces de rede. A primeira olha para a internet. A segunda olha para a DMZ, onde vivem os serviços públicos. A terceira olha para a rede interna. A firewall permite tráfego de entrada da internet para portas específicas na DMZ, permite tráfego estreito da DMZ para o interior onde uma aplicação o exija, e nega tudo o resto.
O nome desta forma é firewall de três pernas. Cada pacote que atravessa entre zonas passa por um único aparelho, o que torna essa firewall um ponto único de falha para o tráfego entre zonas. Se falhar, a conectividade e a aplicação das políticas são afetadas conforme o modo de falha da firewall e a redundância que tiver montado.
Passei uma década a gerir operações de rede num ISP, e o que surpreendia as pessoas numa interface DMZ era como não tinha nada de especial. Uma porta ethernet vulgar com uma etiqueta de confiança diferente atribuída na configuração da firewall. A arquitetura não estava no cobre. Estava no conjunto de regras, e no facto de alguém ter pensado com cuidado em que direção era permitida a cada fluxo.
O modelo de firewall dupla (costas com costas)
Duas firewalls em série, com a DMZ entre elas. A firewall externa deixa passar tráfego da internet para a DMZ e nada além disso. A interna só permite o tráfego específico da DMZ para o interior de que uma aplicação precisa. Um atacante que chegue à DMZ ainda tem de atravessar a fronteira de políticas da firewall interna antes de alcançar a rede interna.
Duas firewalls dão-lhe duas fronteiras de política aplicadas separadamente, mas acrescentam também configuração, atualizações e complexidade operacional. Uma falha ou comprometimento da fronteira externa não remove automaticamente a interna, embora a proteção continue a depender de como as duas firewalls estão configuradas e geridas.
Uma DMZ é o mesmo que uma firewall?
Não. Uma DMZ é uma rede de perímetro ou um segmento de rede separado. Uma firewall é um controlo comum usado para regular o tráfego entre essa zona, a internet e a rede interna. Pode configurar regras de firewall numa rede plana sem criar qualquer DMZ, por isso a distinção é arquitetural e não apenas uma questão de configuração.
A confusão compreende-se. A firewall é o objeto em que se faz login, a coisa com ficheiro de configuração, fornecedor e contrato de suporte, por isso acaba por ficar com o nome daquilo que produz. Ninguém faz login num segmento.
A consequência aparece no pior momento possível. Assuma que o seu servidor web público está comprometido, porque mais cedo ou mais tarde estará. Numa rede plana, o atacante tem agora um ponto de apoio numa máquina que já pode falar com a sua base de dados, o seu servidor de ficheiros e as suas interfaces administrativas, e mover-se entre eles é apenas usar acesso que já estava permitido. A esse deslocamento de lado chama-se movimento lateral, e é exatamente isso que a segunda fronteira existe para travar. A DMZ não impede que o servidor web seja comprometido. Impede que um servidor web comprometido se torne acesso a tudo o resto.
Um esclarecimento enquanto o termo está à frente: a definição "DMZ host" num router doméstico ou de pequeno escritório é outra funcionalidade. Encaminha tráfego de entrada não solicitado para um único dispositivo interno, expondo-o diretamente à internet; não cria uma rede DMZ separada e protegida.
Como aplicar os princípios da DMZ num único servidor?
Um único servidor com um único IP público consegue reproduzir parte do objetivo de controlo da exposição de uma DMZ, sem reproduzir a sua separação de rede. Um proxy reverso pode tornar-se o único ponto de entrada público, regras de firewall de entrada com negação por omissão podem bloquear o resto, e os serviços internos podem escutar em loopback ou numa interface privada em vez do endereço público.
Comece pela restrição que esta secção pressupõe: um VPS, uma interface pública e nenhum equipamento de firewall à parte e nenhuma sub-rede DMZ sob o seu controlo. Nessa montagem, não consegue reproduzir a topologia clássica de três pernas no mesmo host. As regras de firewall no host, a escolha de onde os serviços escutam e um proxy reverso continuam a poder reduzir a exposição, mas não criam a mesma fronteira de isolamento.
Um proxy reverso pode ocupar a interface pública nas portas 80 e 443 e tornar-se o único ponto de entrada ao nível da aplicação para tráfego web. Isso estreita a superfície de ataque pública, mas não equivale a uma interface DMZ separada, porque o proxy continua a partilhar o host com os serviços que estão atrás dele.
As regras de firewall de entrada no host permitem essas duas portas e descartam o resto. Qualquer outro serviço na máquina pode estar a correr e à escuta, mas nada de fora consegue iniciar uma ligação até ele. Isto aproxima a política de "só as portas pretendidas são alcançáveis" num único host; não cria uma fronteira separada com a rede interna.
Os servidores de aplicações, as bases de dados e os painéis de administração não devem escutar no endereço público. Quando o proxy corre no mesmo host, podem escutar em loopback; quando corre noutro ponto da rede privada, podem escutar num endereço privado. Em qualquer dos casos não há um processo à escuta desses serviços na interface pública, pelo que abrir uma regra de entrada apenas nessa interface não os expõe.
O acesso administrativo pertence ao lado interno, não ao lado DMZ. Manter o SSH e as interfaces de gestão fora do caminho público, atrás de uma VPN ou de uma rede privada, impede ligações diretas até eles a partir da internet pública.
Como é que os conceitos de DMZ se mapeiam em sub-redes de VPC e grupos de segurança?
O modelo clássico tem um mapeamento concetual bastante próximo das primitivas de rede da cloud, mas não é um para um. Um segmento DMZ passa a ser uma sub-rede pública. A rede interna passa a ser uma sub-rede privada sem rota para uma gateway de internet. O conjunto de regras da firewall divide-se entre grupos de segurança, associados às interfaces de rede dos recursos, e listas de controlo de acesso de rede, ligadas às sub-redes.
| Elemento clássico | Equivalente na cloud | O que impõe |
|---|---|---|
| Segmento DMZ | Subnet pública | Fornece uma rota para a internet; um recurso precisa ainda de um endereço público e de regras de segurança que permitam o tráfego |
| Segmento de rede interna | Subrede privada | Sem rota direta para a gateway de internet, pelo que a internet não consegue iniciar ligações diretas por esse caminho |
| Interface de firewall entre zonas | Tabela de rotas + ligação de uma gateway de internet | Para onde o tráfego pode ser encaminhado; o endereçamento público e os controlos de segurança continuam a determinar se um recurso é alcançável |
| Conjunto de regras de firewall (por zona) | Listas de controlo de acesso de rede | Regras de permissão e negação sem estado, avaliadas na borda da sub-rede |
| Conjunto de regras de firewall (por host) | Grupos de segurança | Regras de permissão com estado, aplicadas às interfaces de rede dos recursos associados |
| Serviço exposto ao público na DMZ | Balanceador de carga ou instância de proxy na sub-rede pública | O único ponto de entrada por onde o tráfego tem de passar |
Os fornecedores de cloud usam eles próprios este vocabulário, o que é boa prova de que o termo continua atual. O blogue de redes da AWS descreve uma arquitetura DMZ no Amazon VPC que isola os serviços expostos ao público das redes internas, construída sobre o VPC Block Public Access, um controlo ao nível da Região lançado em novembro de 2024.
As sub-redes são a parte que sustenta este mapeamento. Uma sub-rede pública é pública porque a sua tabela de rotas aponta para uma gateway de internet. Como as tabelas de rotas decidem por onde viajam os pacotes, o desenho das sub-redes molda a sua exposição antes de qualquer regra individual.
O mapeamento é imperfeito num ponto específico. Uma interface de firewall impunha uma fronteira para todo um segmento; um grupo de segurança, por seu lado, está associado à interface de rede de um recurso. Duas máquinas na mesma sub-rede privada podem levar grupos de segurança completamente diferentes, pelo que a imposição acontece a uma granularidade mais fina do que uma interface física alguma vez conseguiu. Costuma ser uma melhoria. Também significa que o nome de uma sub-rede lhe diz menos sobre o que é alcançável do que um diagrama de rede dizia antigamente.
Onde a versão de servidor único fica aquém
Num único host, o processo exposto ao público e os serviços internos partilham um kernel e uma máquina. Segmentos separados obrigam um atacante a atravessar uma fronteira de rede que uma firewall inspeciona; um único host não. O padrão de servidor único reduz a exposição. Não reproduz a separação.
Se o proxy reverso for comprometido de uma forma que dê ao atacante execução de código, esse código já está a correr na máquina onde corre a sua base de dados. Escutar em loopback não ajuda nessa altura, porque o loopback é alcançável a partir do próprio host. O isolamento por contentores ou por utilizadores pode elevar o esforço necessário, mas contentores no mesmo host continuam a partilhar o kernel desse host. No modelo clássico, o passo seguinte do atacante era um pacote num cabo que algo inspecionava. Aqui é um socket local.
A consequência prática é um limiar, não um veredicto. Quando aquilo que está atrás do proxy vale mais do que o esforço de uma segunda máquina, use uma segunda máquina e uma rede privada entre as duas. Nada neste artigo tem de ser reaprendido para isso, porque nada disto foi alguma vez sobre o hardware.
Construa num VPS Linux com acesso root, NVMe e o poder do AMD EPYC.
Ver planos LinuxO perímetro já não é o único sítio onde se pode aplicar política de segurança. A arquitetura zero trust remove a confiança implícita baseada na localização de rede, ao passo que a conectividade privada construída com WireGuard ou Tailscale pode reduzir a exposição pública. Nenhuma das duas abordagens substitui automaticamente a segmentação ou a autorização. A minha posição sobre a questão mais estreita é firme. Como modelo mental: separe o que é alcançável do que não é, e saiba que fronteira contém um comprometimento. Essa pergunta sobrevive a todas as arquiteturas nomeadas acima, e é por isso que continua a valer a pena respondê-la.
Perguntas frequentes
Uma DMZ é o mesmo que uma VPN?
Não. Resolvem problemas diferentes. Uma DMZ controla o que estranhos não confiáveis conseguem alcançar, expondo um pequeno conjunto de serviços e mais nada. Uma VPN dá a pessoas de fora em quem se confia um caminho privado para dentro, autenticando-as numa rede que de outro modo não alcançariam. Muitas redes usam ambas, e nenhuma substitui a outra.
Uma DMZ é segura?
Uma DMZ não torna seguro um serviço exposto. Limita até onde chega o comprometimento desse serviço. O serviço virado ao público continua virado ao público, continua exposto a toda a gente na internet e continua a precisar de atualizações, monitorização e reforço por direito próprio. A DMZ decide o que acontece depois de ele cair, não se ele cai.
Preciso de uma DMZ se só tenho um servidor?
Não no sentido clássico, e de qualquer forma não conseguiria construir uma num único host. A topologia de três interfaces exige segmentos de rede separados, e um servidor com um único IP público não tem nenhum. O que pode fazer é controlar a exposição: tornar um proxy reverso o único ponto de entrada público, negar por omissão as restantes portas de entrada, e pôr os serviços internos a escutar em loopback ou num endereço privado. Isso reduz o que a internet consegue alcançar, sem isolar o serviço público do resto do host. Quando aquilo que está atrás do proxy vale mais do que o custo de uma segunda máquina, use duas máquinas e uma rede privada entre elas.
Porque se chama zona desmilitarizada?
O termo é emprestado do sentido militar de uma zona tampão entre duas forças opostas, onde nenhuma manda por completo. O uso em redes mantém a metáfora: a DMZ não pertence inteiramente nem ao exterior não confiável nem ao interior de confiança.
Discussão
Comentários
Inicie sessão para participar na discussão.