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

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

Uma coisa que não podemos descobrir são os possíveis impactos à segurança.

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

No entanto, o agente de implantação na web é executado de forma integrada ao IIS (a única coisa voltada para fora), pois é acessível via http (s). Portanto, tememos que seja potencialmente possível obter acesso ao agente por meio das webs hospedadas nesse IIS - e, assim, 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 Web de produção está executando o IIS7.

Faz algum tempo desde que eu o usei e usei apenas 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, está tudo dentro do IIS; portanto, uma vulnerabilidade no IIS pode tornar as medidas de segurança inúteis até que sejam corrigidas. Por esse motivo, eu hesitaria em permitir a atualização de conteúdo da Web da Internet, mas isso depende dos requisitos de segurança da sua organização e das necessidades do desenvolvedor da web.

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

• fazer com que o site padrão escute um IP somente interno que não seja NAT ou faça parte do intervalo de IP de balanceamento de carga
• você pode fazer com que o site de gerenciamento padrão escute apenas no host local e, em seguida, escreva um script que chame o executável msdeploy em cada host para execução local (em vez de usar o msdeploy para conectar-se remotamente a todos os hosts a partir de um único ponto)
• faça com que seu balanceador de carga filtre solicitações externas que tentam acessar a URL de implantação da web (por exemplo, https: // server: 8081 / MSDeploy )
• tenha um host de implantação designado (interno) de onde todas as suas implantações na web provêm e permita apenas que o IP se conecte aos seus servidores na URL de implantação (bloqueie qualquer coisa que não seja do único host de implantação)

Se ainda for necessário ter a funcionalidade de implantação da Web disponível diretamente na Internet, diga se todos os seus desenvolvedores da Web trabalharam remotamente (não consigo imaginar por que isso seria necessário diretamentecom o uso generalizado da VPN), você pode ter um processo de implantação em dois estágios em que configura uma DMZ isolada com uma caixa IIS 7 habilitada para Implantação da Web (separada da DMZ do seu farm da Web) e permite que os desenvolvedores da Web conecte somente a DMZ da Internet para implantar alterações remotamente. Em seguida, você pode conectar-se internamente a esse host e implantar no restante de seus servidores da web depois de revisar as alterações, os testes etc. Mesmo assim, esse método não apresenta riscos - um usuário mal-intencionado pode acabar comprometendo a funcionalidade de implantação da web, introduzindo algumas código malicioso sem o seu conhecimento e você pode, sem saber, introduzi-lo em seu ambiente de produção.

Resposta simples. SIM, qualquer coisa em execução em qualquer computador abre vetores de ataque. Sempre se deve assumir que existem vulnerabilidades no software. A mitigação é um fator-chave, limita o acesso a redes, usuários, computadores, IPs, etc. Verifique também o acesso físico.

Você também pode restringir o horário em que as atualizações podem acontecer, se o seu firewall puder manipular regras a partir de horários específicos do dia.

Eu recomendo restringir os usuários no (s) servidor (es) da web, ou seja, quem pode fazer a atualização. (Você provavelmente já fez isso). Em seguida, eu usava os firewalls para restringir quais redes (IPs) têm acesso à interface de gerenciamento. Então, se suportado, permitiria que apenas atualizações fossem tratadas durante o horário de trabalho (por meio de uma regra de firewall). Observe que você sempre pode fazer com que o administrador do firewall edite a regra para uma atualização de emergência. Finalmente, observei as vulnerabilidades conhecidas no Web Deployment Agent e reduzi-as ainda mais, ou desativei-as até que uma correção possa ser implementada.