O serviço do agente msdeploy pode abrir um vetor de ataque em nossos servidores?

Question

estamos avaliando o uso do Serviço do Agente de Implantação da Web do msdeploy para implantações automáticas em nossos servidores de produção.

Uma coisa que não podemos descobrir são os potenciais impactos de segurança.

Por um lado, nossos servidores da Web são protegidos (por trás de firewalls e balanceadores de carga), portanto somente o tráfego de http é permitido do lado de fora.

No entanto, o agente de implementação da Web é executado integrado ao IIS (a única coisa voltada para fora), pois é acessível por meio de http (s). Por isso, tememos que possa ser potencialmente possível obter acesso ao agente por meio das redes hospedadas nesse IIS - e, portanto, obter acesso de leitura e gravação a todas as nossas Webs.

Quão seguro é o msdeploy para uso em ambientes de produção?

Atualização: o servidor da Web de produção está executando o IIS7.

    

Answer 1

Já faz algum tempo desde que eu usei, e eu só usei com o IIS 6, que não inclui a parte de gerenciamento da web. Você pode modificar o URL e a porta de gerenciamento remoto e bloqueá-lo no firewall externo. Veja isto: Personalizando e Protegendo o Serviço Remoto . Seu principal mecanismo de segurança parece ser a segurança da conta do usuário, mas, como você disse, tudo está dentro do IIS, portanto, uma vulnerabilidade do IIS pode tornar as medidas de segurança inúteis até que sejam corrigidas. Só por esse motivo, hesitaria em permitir a atualização do conteúdo da web da Internet, mas isso depende dos requisitos de segurança da sua organização em relação às necessidades do desenvolvedor da Web.

Para evitar a exposição do serviço de implementação da Web à Internet, você pode fazer o seguinte:

• faça com que o site padrão ouça em um IP interno somente que não seja NAT ou faça parte do intervalo de IP de balanceamento de carga
• você poderia ter o site de gerenciamento padrão escutando somente localhost e, em seguida, escrever um script que chama o executável msdeploy em cada host para ser executado localmente (em vez de usar o msdeploy para se conectar remotamente a todos os hosts de um único ponto)
• faça com que seu balanceador de carga filtre solicitações externas que tentam atingir a URL de implantação da Web (por exemplo, link )
• ter um host de implantação (interno) designado de onde vêm todas as implantações da web e permitir que o IP se conecte aos seus servidores na URL de implantação (bloqueie qualquer coisa não do único host de implantação)

Se ainda houver necessidade de disponibilizar a funcionalidade de implantação da web diretamente da Internet, se todos os seus desenvolvedores da Web trabalharem remotamente, (não consigo imaginar por que isso seria necessário diretamente com a disseminação uso de VPN), você pode ter um processo de implantação de dois estágios em que você configura uma DMZ isolada com uma caixa do IIS 7 habilitada para Web Deploy nela (separada da DMZ da web farm) e permite que seus desenvolvedores da Web se conectem apenas que DMZ da internet para implantar alterações remotamente. Então você poderia se conectar internamente a esse host e implantar para o resto de seus servidores web depois de revisar as alterações, testes, etc. Mesmo este método não é isento de riscos - um usuário mal-intencionado pode comprometer a funcionalidade de implantação web, introduzindo alguns código malicioso sem o seu conhecimento e você pode, sem saber, introduzi-lo em seu ambiente de produção.

    

Answer 2

Resposta simples. Sim, qualquer coisa em execução em qualquer computador abre vetores de ataque. Deve sempre ser assumido que existem vulnerabilidades no software. A atenuação é um fator-chave, limita o acesso a redes, usuários, computadores, IPs etc. Além disso, verifique o acesso físico.

Você também pode restringir o tempo que as atualizações são permitidas, se o seu firewall puder lidar com regras de horários específicos do dia.

Eu recomendaria a restrição de usuários em seu (s) servidor (es) web, ou seja, quem pode fazer a atualização. (Você provavelmente já fez isso) Então eu usaria os firewalls para restringir quais redes (IPs) têm acesso à interface de gerenciamento. Então, se suportado, só permitirei que as atualizações sejam tratadas durante o horário de trabalho (por meio de uma regra de firewall). Note que você sempre pode ter o administrador do firewall editando a regra para uma atualização de emergência. Finalmente, eu observaria vulnerabilidades conhecidas no Agente de Implantação da Web & diminuir ainda mais ou desativá-lo até que uma correção possa ser implementada.