Servidores na DMZ

[Grall Fernandes]

Em conjunto com outros equipamentos de uma DMZ
Para os pacotes que chegam ao gateway VPN, têm-se após a retirada do cabeçalho ESP (no modo
túnel), endereços de origem de dois tipos: de rede privada, válidos Internet (sejam eles internos ou externos à
rede na qual se localiza o gateway VPN).
Para os endereços de rede privada, existem circulando num mesmo cabo pacotes com endereços de
origem privados e com endereços de origem roteáveis externamente. Conforme as regras de filtragem existentes,
isto pode vir a ser um problema. Normalmente, para se evitar o spoofing de endereços IP, é aconselhável não
permitir a entrada numa interface de rede, de pacotes cujos endereços de origem não sejam daqueles que
normalmente circulariam naquele segmento de rede. Abrindo uma exceção à alguns endereços pode-se gerar
precedente perigoso de ataque à uma rede. Entretanto, se os pacotes não possuem endereços de origem internos
(privados ou não), não se pode usufruir de imediato, da vantagem de se ver a outra rede, ou máquina, como
integrante lógica da rede interna.
Para os endereços Internet válidos, têm-se pacotes de origem externos à rede, pertencentes à DMZ ou
internos (porém não da faixa privada). Em relação aos pacotes com endereços internos, o problema foi discutido
no parágrafo anterior. Os demais pacotes não teriam a aparência de serem originários de uma máquina da rede
interna.
Exitem vantagens e desvantages em DMZ separada e conjuntto com citado acima

[Grall Fernandes]

Uma solução é utilizar-se, no roteamento entre a DMZ e a rede interna, de um serviço de NAT reverso. Deste
modo pode-se ter pacotes tunelados com endereços de origem externos, sendo que o NAT reverso se encarregaria de transformá-los em endereços válidos dentro da rede interna. A rede interna veria estes pacotes
como oriundos dela

[lordsithius]

Não vejo lógica para isso !!!

Colocando o Servidor Web na DMZ você vai expor ele mais ainda ... Se quer criar uma DMZ então insira um servidor de monitoramento para rastrear tentativas de acesso em seu perimetro e não exponha o próprio servidor Web dentro dessa zona ...

Na minha opinião se tem um bom firewall não há motivo pra criação de DMZ ...

[mmachado]

Na minha opinião se tem um bom firewall não há motivo pra criação de DMZ ...

Como o seu "bom firewall" vai ajudar caso o servidor seja comprometido por uma falha no serviço que ele deve prestar de forma legítima, vamos supor, uma injeção de códigos nas páginas ASP que permitam controlar o banco de dados sob as prerrogativas do user SYSTEM?

Deixar esta máquina longe do ambiente interno é uma opção mais adequada sem com isso, no entanto, negligenciar a implantação de bons firewalls. DMZ costuma ter um custo relativamente baixo. Não vejo motivos para não implementá-la.

[]s, MM

[ubaid]

A DMZ server para manter todos serviços públicos (acessados a partir da internet). Um servidor WEB deve estar em uma DMZ ou então ter um proxy reverso na DMZ recebendo as requisições.

Como seu ambiente é pequeno (caso seja grande e vc ainda não possui uma DMZ, é melhor rever toda sua rede), a melhor solução é mover o servidor web para a DMZ.

Como a DMZ é um segmento considerado menos seguro, lá não devem existir informações confidenciais, e muito menos alguma máquina da DMZ fazer parte do domínio da rede interna.

O acesso de terminal services, por ser utilizado para administração remota, a recomendação é utiliza-lo através de uma VPN (no mínimo).

Nem pense em honeypot, eles são utilizados para estudo de ataques, não aumentando em nada a segurança do ambiente onde estão instalados.

[Guzpido Krush]

Falando em honeypot e servidor web,
eu me interessei muito por esse tal de GHH

GHH - The "Google Hack" Honeypot

alguém já usou?