Can the msdeploy agent service open up an attack vector on our servers?

we're evaluating the usage of the msdeploy Web Deployment Agent Service for automatic deployments to our production servers.

One thing we can't find out about are potential security impacts.

For one thing, our web servers are of course secured (behind firewalls and load balancers) so only http(s) traffic is allowed from the outside.

Nevertheless, the web deployment agent runs integrated with IIS (the only thing facing outside), as it is accessible via http(s). So we fear that it could be potentially possible to gain access to the agent through the webs hosted on that IIS - and hereby gaining read and write access to all our webs.

How secure is msdeploy for usage in production environments?

Update: Production web server are running IIS7.

Solution 1:

It's been awhile since I used it, and I only used it with IIS 6 which doesn't include the web management part. You can modify the remote management URL and port and block it at the external firewall. See this: Customizing and Securing the Remote Service. It's main security mechanism appears to be user account security, but like you said, it's all within IIS, so an IIS vulnerability could render the security measures useless until patched. For that reason alone, I would be hesitant to allow updating web content from the internet, but this depends on your org's security requirements vs. your web developer's needs.

To avoid exposing the web deploy service to the internet, you can do the following:

• have the default website listen on an internal-only IP that is not NATed or part of the load-balancing IP range
• you could have the default management website listen on localhost only, then write a script that calls the msdeploy executable on each host to run locally (instead of using msdeploy to connect remotely to all hosts from a single point)
• have your load-balancer filter external requests that try to hit the web deploy URL (ex. https://server:8081/MSDeploy)
• have a designated (internal) deployment host that all your web deployments come from and only allow that IP to connect to your webservers on the deployment URL (block anything not from the single deployment host)

If there still a need to have web deployment functionality available directly from the internet say if all of your web developers worked remotely, (I can't imagine why this would be necessary directly with the widespread usage of VPN), you could have a 2-stage deployment process where you set up an isolated DMZ with a Web Deploy-enabled IIS 7 box in it (separate from your web farm's DMZ), and allow your web developers to connect to only that DMZ from the internet to deploy changes remotely. Then you could connect internally to that host and deploy to the rest of your web servers after reviewing the changes, testing, etc. Even this method isn't without risks though - a malicious user may end up compromising the web deployment functionality, introducing some malicious code without your knowledge and you could unknowingly introduce it into your production environment.