Может ли служба агента msdeploy открыть вектор атаки на наших серверах?

мы оцениваем использование службы агента сетевого развертывания msdeploy для автоматического развертывания на наших производственных серверах.

Одна вещь, о которой мы не можем узнать, это потенциальные воздействия на безопасность.

Во-первых, наши веб-серверы, конечно, защищены (за брандмауэрами и балансировщиками нагрузки), поэтому снаружи разрешен только http (s) трафик.

Тем не менее, агент веб-развертывания работает интегрированно с IIS (единственное, что находится снаружи), так как он доступен через http (s). Поэтому мы опасаемся, что потенциально возможно получить доступ к агенту через веб-сайты, размещенные на этом IIS, и тем самым получить доступ для чтения и записи ко всем нашим сетям.

Насколько безопасен msdeploy для использования в производственных средах?

Обновление: производственный веб-сервер работает под управлением IIS7.

Прошло некоторое время с тех пор, как я использовал его, и я использовал его только с IIS 6, который не включает в себя часть веб-управления. Вы можете изменить URL-адрес и порт удаленного управления и заблокировать его на внешнем брандмауэре. Смотрите это: Настройка и защита удаленного сервиса . Его основным механизмом безопасности является безопасность учетных записей пользователей, но, как вы сказали, все это в IIS, поэтому уязвимость IIS может сделать меры безопасности бесполезными до тех пор, пока они не будут исправлены. Только по этой причине я не хотел бы разрешать обновление веб-контента из Интернета, но это зависит от требований безопасности вашей организации и от потребностей вашего веб-разработчика.

Чтобы не подвергать службу веб-развертывания Интернету, вы можете сделать следующее:

• веб-сайт по умолчанию прослушивает внутренний IP-адрес, который не является NAT или частью диапазона IP-адресов с балансировкой нагрузки
• веб-сайт управления по умолчанию может прослушивать только localhost, а затем написать скрипт, который вызывает исполняемый файл msdeploy на каждом хосте для локального запуска (вместо использования msdeploy для удаленного подключения ко всем хостам из одной точки)
• ваш балансировщик нагрузки отфильтровывает внешние запросы, которые пытаются попасть на URL веб-развертывания (например, https: // server: 8081 / MSDeploy )
• иметь назначенный (внутренний) хост развертывания, с которого поступают все ваши веб-развертывания, и разрешать этому IP-адресу подключаться к вашим веб-серверам только по URL-адресу развертывания (блокировать все, что не от одного хоста развертывания)

Если по-прежнему необходимо, чтобы функциональность веб-развертывания была доступна непосредственно из Интернета, скажем, работали ли все ваши веб-разработчики удаленно (я не могу представить, почему это было бы необходимо напрямую).с широко распространенным использованием VPN), у вас может быть двухэтапный процесс развертывания, в котором вы создадите изолированную DMZ с включенным в нее блоком IIS 7 с поддержкой веб-развертывания (отдельно от DMZ вашей веб-фермы) и позволите вашим веб-разработчикам подключаться только к этой DMZ из интернета для удаленного развертывания изменений. Затем вы можете подключиться к этому хосту и развернуть его на остальных веб-серверах после проверки изменений, тестирования и т. Д. Однако даже этот метод не лишен рисков - злоумышленник может в конечном итоге поставить под угрозу функциональность веб-развертывания, представив некоторые вредоносный код без вашего ведома, и вы можете неосознанно внедрить его в свою производственную среду.

Простой ответ ДА, все, что работает на любом компьютере, открывает векторы атаки. Всегда следует предполагать, что существуют уязвимости в программном обеспечении. Смягчение является ключевым фактором, ограничивающим доступ к сетям, пользователям, компьютерам, IP-адресам и т. Д. Также проверьте физический доступ.

Вы также можете ограничить время, в течение которого могут происходить обновления, если ваш брандмауэр может обрабатывать правила с определенного времени суток.

Я бы порекомендовал ограничить пользователей на вашем веб-сервере (ах), т.е. кто может делать обновление. (Вы, вероятно, уже сделали это). Тогда я бы использовал брандмауэры, чтобы ограничить, какие сети (IP) имеют доступ к интерфейсу управления. Тогда, если поддерживается, я позволю обрабатывать обновления только в рабочее время (через правило брандмауэра). Обратите внимание, что администратор брандмауэра всегда может изменить правило для экстренного обновления. Наконец, я отслеживал известные уязвимости в агенте веб-развертывания и продолжал их устранять, либо отключал их до тех пор, пока не будет реализовано исправление.