13

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.

Sebastian P.R. Gingter
  • 226
  • 1
  • 4
  • 13

2 Answers2

10

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.

August
  • 3,114
  • 15
  • 17
  • Updates would only be done from a secured VPN access to the production servers, so no access from the internet is necessary. I still have a bad feeling about installing something that can change web server configurations. Right now, the people with 'deploy permissions' have SFTP access to their specific web folders only, the web servers are not in a domain and totally isolated in any other way. – Sebastian P.R. Gingter Sep 12 '11 at 15:21
  • 1
    normally I would agree with "I still have a bad feeling about installing something that can change web server configurations.", but in this case, where you have a web farm, the chances of misconfiguring something on one of the servers and opening up an unintended hole via a manual update process is far more likely and risky than enabling a service that ensures a consistent configuration on all your web servers. – August Sep 12 '11 at 15:35
  • Okay, I would take it as "it's probably secure enough to take the risk in exchange for the chances of the easier automated deployment". Thanks. – Sebastian P.R. Gingter Sep 12 '11 at 16:25
0

Simple answer. YES, Anything running on any computer opens attack vectors. It should always be assumed that there are vulnerabilities in software. Mitigation is a key factor, limit access to networks, users, computers, IPs, etc. Also Check physical access.

You could also restrict the time updates are allowed to happen, if your firewall can handle rules from specific times of day.

I'd recommend restricting users on your web server(s), ie who can do the update. (You've probably already done this) Then I'd use the firewalls to restrict what networks (IPs) have access to the management interface. Then if supported I'd only allow updates to be handled during working hours (via a firewall rule). Note you can always have the firewall admin edit the rule for an emergency update. Finally I'd watch for known vulnerabilities in the Web Deployment Agent & mitigate further, or disable it until a fix can be implemented.

tkrabec
  • 300
  • 1
  • 6