Немного предыстории, я не системный администратор, но слышал, как мы обсуждали эту самую проблему, и хотел сам разобраться в ней.
Мы запускаем внутреннюю сеть с множеством виртуальных машин (и некоторых физических хостов), у которых нет доступа в Интернет. Виртуальные машины постоянно создаются, изменяются, удаляются и многое другое добавляется. Однако виртуальные машины должны быть исправлены и обновлены. У нас есть локальная машина WSUS, которая извлекает WU и распространяет их на компьютеры в домене.
У меня вопрос: Можно ли перенаправить обновления Windows на наш внутренний WSUS с помощью записи DNS? В более общем смысле, это для устройств, не относящихся к GPO и не принадлежащих домену (поэтому вручную изменять записи реестра нельзя).
Если это невозможноНе могли бы вы кратко рассказать, почему эта идея не работает?
Вкратце, Центр обновления Windows работает, отправляя серию запросов веб-служб в известную конечную точку, управляемую Microsoft - скажем, только ради примера, эта конечная точка https://update.microsoft.com. Оттуда он делает дальнейшие запросы к другим конечным точкам, управляемым Microsoft, потому что исходный ответ сообщает им (например, перенаправления для балансировки нагрузки) - допустим, это могут быть https://update1.microsoft.com, https://wu2.update.microsoft.com и https://windowsupdate.largescalecontenthost.net.
В качестве аргумента / примера давайте также предположим, что спецификация веб-службы для общедоступного Центра обновления Windows точно такая же, как и для WSUS, и в запросах нет ничего другого, что идентифицирует его как запрос WU, а не как WSUS. запрос.
Ваша гипотеза заключается в том, что, если вы можете перехватить все запросы, которые может сделать Центр обновления Windows, и вместо этого направить их на свой сервер WSUS, вы мощь иметь возможность заставить ваших неуправляемых клиентов использовать ваш WSUS.
На практике, однако, у вас есть лишь несколько способов перехватить этот трафик:
Вы настраиваете DNS-прокси: Используя наш пример настройки, вам понадобятся корни зон для microsoft.com и largescalecontenthost.net. Это позволит вам изменить IP-адреса, которые получают ваши DNS-клиенты, чтобы он получал IP-адрес вашего сервера WSUS вместо реальной службы Windows Update. Вот некоторые головные боли, которые я вижу в этом:
Поддерживать перехватывающий DNS-прокси сложно. IP-адреса и имена служб в устойчивых высокодоступных службах постоянно меняются. Вам придется идти в ногу с этими изменениями. Они могут использовать largescalecontenthost.net сейчас, но через неделю они могут измениться на anothercontenthost.net, и их тоже нужно перехватить.
Поддерживать перехватывающий DNS-прокси сложно. Если ваши DNS-клиенты (то есть ваши конечные пользователи) действительно хотят получить реальный адрес в microsoft.com, ваш прокси должен будет знать, чтобы игнорировать это значение и получить реальное значение от сервера пересылки.
Вмешаться в зашифрованный трафик сложно. Трафик основан на HTTPS, что означает, что трафик сервера подписывается с использованием закрытого ключа, известного только действующим серверам Центра обновления Windows, которые отправляют общедоступный сертификат как часть трафика, а клиент WU использует оба для проверки законности трафика. Если ваш сервер WSUS действительно получил этот трафик, он отправит свой собственный сертификат. Клиент Центра обновления Windows будет проверять этот сертификат, используя (как минимум) Subject информация, содержащаяся в сертификате. это вряд ли что вы сможете получить сертификат (ы) со значениями Subject или SubjectAltName, которые заканчиваются на microsoft.com или largescalecontenthost.net, потому что вы не владеете этими доменами. Хорошо функционирующие центры сертификации не выполнят запрос на домен, которым вы не владеете; и центры сертификации, которые мощь позволяют это, как правило, не остаются в цепочке доверия Windows очень долго.
Вы настраиваете DNS-прокси и свой собственный внутренний ЦС: Вы используете внутренний центр сертификации для выдачи поддельных сертификатов для update.microsoft.com, update1.microsoft.com, wu2.update.microsoft.com и windowsupdate.largescalecontenthost.net. Вот некоторые головные боли, которые я вижу в этом:
Вмешаться в зашифрованный трафик сложно. Вам придется продолжать выдавать их для любых альтернативных имен хостов, которые появляются во время запросов, сделанных Центром обновления Windows. Вероятно, вы не сразу узнаете, что это запросы из Центра обновления Windows, потому что вы не смогли бы их проверить, потому что они зашифрованы. Таким образом, вам понадобится автономный источник этих имен хостов для поддержки вашего процесса.
Вмешаться в зашифрованный трафик сложно. Ни один из ваших клиентов конечных пользователей (то есть ваших виртуальных машин) не будет доверять вашим поддельным сертификатам, потому что вы не импортировали цепочку в свои хранилища доверенных корней. Вам нужно будет перейти на каждую машину и импортировать доверенный корневой сертификат. Пока вы это делаете, вы можете также установить ключи реестра, которые в первую очередь должны указывать на сервер WSUS.
Вы настраиваете DNS-прокси, свой собственный внутренний ЦС, вы выдвигаете корень ЦС всем своим клиентам и реализуете исходящий обратный прокси-сервер TLS.: Теперь ваш обратный прокси-сервер TLS может расшифровывать трафик, отправленный и полученный WU, создавать поддельные сертификаты на лету на основе того, что требуется WSUS, и, если вы каким-то образом перехватите это, чтобы перезаписать DNS на лету, все запросы клиентов WU покрыты. Ваши клиенты доверяют поддельным сертификатам, потому что корень был импортирован повсюду. У некоторых крупных продавцов есть оборудование, которое может утверждать, что делает именно это, достаточно надежно, за определенную цену. Следующий набор головных болей:
Решить, что расшифровать, сложно. Вы также хотите перехватить интернет-банкинг вашей финансовой команды? Ваш обратный прокси-сервер, вероятно, уже делает это. Возможно, у вас есть корпоративная политика, которая не заботится об этом, но я ожидаю, что вам придется поддерживать целую кучу белых списков, которые предотвращают отслеживание вашего прокси-сервера любого трафика с разумным ожиданием конфиденциальности.
Вмешаться в зашифрованный трафик сложно. Многие сайты пытаются противостоять таким прокси. Прикрепление открытого ключа находится в упадке (потому что это сложно сделать правильно), но это достаточно эффективный инструмент против выдачи поддельных сертификатов. Google, вероятно, перестанет работать, поскольку они прикрепляют свои сертификаты прямо в Chrome. Прокси-сервер можно настроить на удаление заголовков Public Key Pins из ответа, но все еще слишком поздно для любого из ваших конечных пользователей, которые когда-либо уже были на этих сайтах.
Теперь рассмотрим альтернативу: Предварительно заполните файл экспорта реестра Windows несколькими минимальными значениями, необходимыми для направления клиента Центра обновления Windows на ваш сервер WSUS. Войдите во все свои виртуальные машины и импортируйте файл реестра. Обновите свои золотые образы / шаблоны, чтобы новые виртуальные машины получали эти настройки автоматически. Обновите документацию по процессу, чтобы инженеры по сборке знали, что нужно включить эти параметры. Оплакивайте неделю, когда вам приходилось входить во все свое поместье и обновлять настройки вручную, и подумайте, как вы могли бы облегчить эти ручные усилия в будущем - например, приведение всего в соответствие с доменной архитектурой (даже легкой) или развертывание инструмента автоматизации, такого как Salt, Otter, или даже междоменного удаленного взаимодействия Powershell - так что вам больше никогда не придется страдать от этого.
На практике, Я собираюсь поспорить (если ваша ИТ-команда действительно методична), что есть наверное секретную общую учетную запись на каждой из этих разрозненных виртуальных машин. Если не обычная учетная запись, то секретный список компьютеров и учетных данных. Если это так, вы, вероятно, сможете установить параметры реестра для 80% этих машин с помощью одного хорошо написанного командного файла.
Если нет, то повседневные задачи обслуживания ИТ-отдела, вероятно, станут для них серьезной проблемой.
Нет, ты не можешь. В дополнение к причинам, указанным в других ответах, Microsoft жестко закодировала определенные DNS-имена в Windows, чтобы их нельзя было переопределить с помощью поиска DNS, даже с помощью записей в файле hosts. Сюда входят имена первых контактных лиц Центра обновления Windows.
Для получения дополнительной информации см. Эту статью: https://www.petri.com/windows-10-ignoring-hosts-file-specific-name-resolution
Нет, с DNS этого сделать нельзя. Я могу назвать вам две причины:
Это не поддерживается Microsoft. Для меня это запрет на производственную среду, последствия могут быть непредсказуемыми.
Имена DNS могут измениться в любое время, и они будут изменены в любое время! Центр обновления Майкрософт использует глобальную сеть CDN с геокэшированием с множеством разных доменов, вы не можете добавить их все на свой DNS-сервер. Когда вы спрашиваете Microsoft о списке DNS-имен, используемых Центром обновления Microsoft, они дают вам домены с подстановочными знаками: https://support.microsoft.com/en-us/help/3084568/can-t-download-updates-from-windows-update-from-behind-a-firewall-or-p