Qual o tamanho de um problema é perfurar um buraco na DMZ em um servidor web?


15

Atualmente, temos nosso servidor web em uma DMZ. O servidor da web não pode ver nada na rede interna, mas a rede interna pode ver o servidor da web. Quão seguro seria fazer um furo no firewall entre a DMZ e a rede interna para apenas um servidor Web na intranet? Estamos trabalhando em algo que fará interface com vários de nossos aplicativos de back-office (que estã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 contém esses dados ( via serviços da Web).

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

Então, algo como:

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

Que tal alguns detalhes, como que tipo de firewall está fornecendo essa DMZ?
SpacemanSpiff

@ SpacemanSpiff Tentei com o conhecimento mínimo que tenho da rede. Sou desenvolvedor que planeja este próximo projeto e cria opções.
Mike Wills

Respostas:


25

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 atingir o resultado pretendido. Talvez não seja preferível fazê-lo, mas às vezes é a única maneira de fazer 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, juntamente com os protocolos específicos (portas TCP e / ou UDP) que serão usados. Basicamente, abra apenas um orifício pequeno, conforme necessário.

  • Certifique-se de registrar o acesso do host DMZ ao host na rede protegida e, se possível, analise esses logs de maneira 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 indiretamente, à Internet. Fique por dentro das correções 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 for possível com a arquitetura do aplicativo. Seria bom saber que os pedidos que chegam ao host interno são realmente provenientes do host DMZ. Se você pode fazer isso ou não, isso depende muito da arquitetura do 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 eles serão efetivamente o host DMZ).

  • Se houver preocupação com os ataques de negação de serviço, considere o uso de limite de taxa para impedir que o host DMZ esgote os recursos do host interno.

  • Você pode considerar o uso de uma abordagem de "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 integridade e depois passá-las para o host de back-end "real". Como você está falando sobre a interface com seus aplicativos de back-office no IBM iSeries, suponho 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 o assunto, não há motivo para não fazer o que está descrevendo, mantendo o risco minimizado ao mesmo tempo.

Sinceramente, o fato de você ter uma DMZ que não tem acesso irrestrito à rede protegida coloca você aos trancos e barrancos além de muitas redes que já vi. Para algumas pessoas, ao que parece, DMZ significa apenas "outra interface no firewall, possivelmente com endereços RFC 1918 diferentes, e basicamente acesso irrestrito à Internet e à rede protegida". Tente manter sua DMZ o mais fechada possível, enquanto cumpre as metas de negócios e você se sai bem.


Resposta mais completa do que a minha :) +1
Matthew

Eu amo essa informação. Antes de perguntar, eu entendi algumas das coisas sobre as quais você falou. Mas muito disso eu não entendi completamente. Obrigado!
Mike Wills

Isso depende do que você quer dizer com verificações de sanidade. Em um caso como esse, evitamos o máximo possível de SQL (já que o RPG pode "ler" bancos de dados) e validar os dados recebidos antes de processá-los. Além disso, a maioria dos dados inseridos no software de back-office provavelmente seria adicionada a uma "caixa de entrada" para os funcionários lidarem manualmente.
Mike Wills

6

Obviamente, existem alguns perigos, mas você pode fazê-lo. Basicamente, você está abrindo um buraco onde alguém poderia entrar, então diminua. Limite-o apenas aos servidores de ambos os lados e permita apenas dados nas portas escolhidas. Não é uma má idéia usar a conversão de endereço de porta para usar apenas portas bizarras. Ainda assim, segurança pela obscuridade não é segurança alguma. Certifique-se de que o servidor do outro lado tenha algum tipo de maneira de verificar se as informações que passam por essa conexão realmente são as que parecem ser ... ou pelo menos ter algum tipo de firewall com reconhecimento de contexto. Além disso, existem certos firewalls feitos para esse tipo de coisa ... Eu sei que o Microsoft ISA faz a mesma coisa para servidores OWA e Exchange.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.