Чи може служба агента msdeploy відкрити вектор атаки на наших серверах?

ми оцінюємо використання служби агента веб-розгортання msdeploy для автоматичного розгортання на наші виробничі сервери.

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

З одного боку, наші веб-сервери, безумовно, захищені (позаду між брандмауерами та балансирами завантаження), тому ззовні допускається лише http (і) трафік.

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

Наскільки безпечний msdeploy для використання у виробничих середовищах?

Оновлення: Веб-сервер виробництва працює під керуванням IIS7.

Минуло деякий час, коли я використовував його, і я використовував його лише з IIS 6, який не включає частину веб-управління. Ви можете змінити URL-адресу та порт віддаленого управління та заблокувати його на зовнішньому брандмауері. Дивіться це: Настроювання та безпека віддаленого сервісу . Основним механізмом безпеки, схоже, є захист облікових записів користувачів, але, як ви вже сказали, це все в IIS, тому вразливість IIS може зробити заходи безпеки марними до виправлення. Тільки з цієї причини я б вагався дозволити оновлення веб-контенту з Інтернету, але це залежить від вимог безпеки вашого органу щодо потреб вашого веб-розробника.

Щоб уникнути відкриття послуги веб-розгортання в Інтернеті, ви можете зробити наступне:

• веб-сайт за замовчуванням прослуховує лише внутрішній IP, який не є NATED або є частиною діапазону IP-балансування навантаження
• у вас може бути веб-сайт управління за замовчуванням прослуховувати лише у localhost, а потім написати сценарій, який викликає виконуваний файл msdeploy на кожному хості для запуску локально (замість того, щоб використовувати msdeploy для віддаленого підключення до всіх хостів з однієї точки)
• мати зовнішній запит фільтра балансира навантаження, який намагається потрапити на URL розгортання веб-сторінки (наприклад, https: // сервер: 8081 / MSDeploy )
• мати призначеного (внутрішнього) вузла розгортання , що всі ваші веб - розгортання прийшли і тільки допустити , що IP для підключення до веб - серверів на URL розгортання (блок нічого НЕ від одного хоста розгортання)

Якщо все ж є необхідність у доступності функцій веб-розгортання безпосередньо з Інтернету, скажіть, якщо всі ваші веб-розробники працювали віддалено, (я не уявляю, чому це було б потрібно безпосередньопри широкому використанні VPN), ви можете мати двоступеневий процес розгортання, коли ви встановите ізольований DMZ з полем IIS 7 з підтримкою веб-розгортання (окремо від DMZ вашого веб-ферми) та дозволите веб-розробникам підключіться лише до цього DMZ з Інтернету, щоб віддалено розгорнути зміни. Тоді ви зможете внутрішньо підключитися до цього хоста та розгорнутись на інші веб-сервери після перегляду змін, тестування тощо. Навіть цей метод не без ризиків, але зловмисний користувач може поставити під загрозу функціонування веб-розгортання, запровадивши деякі шкідливий код без вашого відома, і ви можете несвідомо ввести його у виробниче середовище.

Проста відповідь. Так, все, що працює на будь-якому комп’ютері, відкриває вектори атаки. Завжди слід вважати, що в програмному забезпеченні є вразливості. Пом'якшення наслідків є ключовим фактором, обмежте доступ до мереж, користувачів, комп'ютерів, IP-адрес тощо. Також перевірте фізичний доступ.

Ви також можете обмежити час дозволу на оновлення часу, якщо ваш брандмауер може керувати правилами в певний час доби.

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