Qual é o tamanho do problema para fazer um furo no DMZ para um servidor web?

Question

Atualmente, temos nosso servidor da web em uma DMZ. O servidor da web não pode ver nada dentro da rede interna, mas a rede interna pode ver o servidor da web. Quão seguro seria abrir um buraco no firewall entre a DMZ e a rede interna para apenas um servidor da Web na intranet? Estamos trabalhando em algo que fará interface com vários de nossos aplicativos de back-office (que são todos em um servidor) e seria muito mais fácil fazer esse projeto se pudéssemos nos comunicar diretamente com o servidor IBM i que mantém esses dados ( via web services).

Pelo que entendi (e não conheço marcas), temos um firewall para o DMZ com um IP externo diferente do nosso IP principal com outro firewall. Outro firewall é entre o servidor da Web e a intranet.

Então, algo como:

Web Server  <==== Firewall ===== Intranet
     |                              |
     |                              |
  Firewall                      Firewall
     |                              |
     |                              |
 Internet IP1                  Internet IP2

    

Answer 1

Não há nada de errado em criar mecanismos de acesso para hosts na DMZ para acessar hosts na rede protegida quando isso for necessário para alcançar o resultado pretendido. Talvez não seja preferível fazê-lo, mas às vezes é a única maneira de realizar o trabalho.

As principais coisas a considerar são:

• Limite o acesso à regra de firewall mais específica possível. Se possível, nomeie os hosts específicos envolvidos na regra junto com os protocolos específicos (portas TCP e / ou UDP) que serão usados. Basicamente, abra apenas um buraco tão pequeno quanto necessário.

• Verifique se você está registrando o acesso do host da DMZ ao host na rede protegida e, se possível, analise esses registros de forma automatizada em busca de anomalias. Você quer saber quando algo fora do comum acontece.

• Reconheça que você está expondo um host interno, mesmo que de maneira indireta, à Internet. Fique por dentro dos patches e atualizações do software que você está expondo e do próprio software do sistema operacional do host.

• Considere a autenticação mútua entre o host DMZ e o host interno, se isso for possível com a arquitetura do seu aplicativo. Seria bom saber que as solicitações que chegam ao host interno são realmente provenientes do host DMZ. Se você pode fazer isso ou não, será altamente dependente da arquitetura do seu aplicativo. Além disso, lembre-se de que alguém que "possui" o host DMZ poderá fazer solicitações ao host interno mesmo se a autenticação estiver ocorrendo (já que, efetivamente, será o host DMZ).

• Se houver preocupação com ataques DoS, considere o uso de limitação de taxa para evitar que o host DMZ esgote os recursos do host interno.

• Você pode considerar o uso de uma abordagem "firewall" da camada 7, em que as solicitações do host DMZ são passadas primeiro para um host interno de finalidade especial que pode "higienizar" as solicitações, verificá-las com sanidade, e depois passá-los para o host back-end "real". Como você está falando sobre a interface com seus aplicativos de back-office em seu IBM iSeries, estou supondo que você tenha capacidade limitada para executar verificações de sanidade contra solicitações recebidas no próprio iSeries.

Se você abordar isso de maneira metódica e manter algum senso comum sobre isso, não há motivo para que você não possa fazer o que está descrevendo, mantendo o risco minimizado ao mesmo tempo.

Francamente, o fato de você ter uma DMZ sem acesso irrestrito à rede protegida aumenta muito o número de redes que já vi. Para algumas pessoas, ao que parece, DMZ significa apenas "outra interface no firewall, possivelmente com alguns endereços RFC 1918 diferentes e basicamente acesso irrestrito à Internet e à rede protegida". Tente manter sua DMZ tão bloqueada quanto possível enquanto ainda estiver realizando metas de negócios e se sair bem.

    

Answer 2

Existem obviamente alguns perigos, mas você pode fazê-lo. Basicamente, você está abrindo um buraco que alguém poderia entrar, então diminua. Limite-o apenas aos servidores em ambas as extremidades e permita apenas dados nas portas escolhidas. Não é uma má idéia usar a tradução de endereços de porta para usar apenas portas bizarras. Ainda assim, segurança por obscuridade não é segurança alguma. Certifique-se de que qualquer que seja o servidor do outro lado tem algum tipo de maneira de verificar que a informação que passa por essa conexão é realmente o que parece ser ... ou pelo menos ter algum tipo de firewall ciente do contexto. Além disso, existem certos firewalls feitos para esse tipo de coisa ... Sei que o microsoft ISA faz a mesma coisa para servidores do OWA e do Exchange.