О проблемах установки обновлений


Своевременная установка обновлений это хорошая профилактика от вирусных атак. Это ещё раз подтверждает последння волна червей, начавшаяся с WannaCry.

И вот вроде бы все нужные обновления регулярно ставим, но червь как-то просочился на несколько компьютеров. По совокупности защитных мер ничего страшного не произошло, тем не менее выводы на будущее надо было сделать.

Стали анализировать возможные пути проникновения. Ниже описание полученного опыта только по линии установки обновлений. Ничего нового, как обычно: неустановленные обновления и поврежденные системы.

1. «Оказалось», что существует некоторое количество «супер важных» пользователей и рабочих мест, где ну никак нельзя прерывать работу для установки обновлений, и на системах которых выставлен режим «загрузить и ждать ручной установки». И конечно добившись этого пользователи просто забыли про обязательство регулярно ставить обновления вручную, а те, кто должен был за этим следить, также игнорировали эту работу (кому хочется лишний раз общаться со скандальными пользователями да ещё по собственной инициативе). В результате червь сумел прыгнуть на эти системы. К счастью для «супер важных» червь был задушен другими средствами и не смог зашифровать документы. Тем не менее системы были переустановлены как скомпроментированные.

Вывод: в публичной сети (корпоративная сеть также публичная) нужно принудительно обновлять системы невзирая ни на что — вирусные атаки это обыденное дело и одна из таких атак неизбежно уничтожит всё, если каждый день не работать над защитой, хотя бы по минимому. Должность и скандальность никак не защищают от вирусных атак.

2. WSUS давний и надежный помошник в установке обновлений и контроле за этим процессом. Тем не менее выяснилось, что есть некоторое количество клиентов, которые регулярно шлют положительные отчеты на WSUS, но по факту не детектят и, соответственно, не устанавливают обновления. По сути существует три подсистемы установки обновлений: антивирус, система и Office. Мы обнаружили компьютеры, где антивирус регулярно устанавливал обновления через Windows Update Agent и отправлял положительные отчеты на WSUS, но две другие подсистемы установки обновлений не работали (даже не пытались ничего ставить, поэтому и ошибок не было).

Вывод: нельзя полностью полагаться на отчеты WSUS, т.к. есть ситуации, когда проблемные компьютеры незаметны в них. Отследить проблему по количеству установленных обновлений не так просто, потому что компьютеры различаются по установленному ПО и компонентам.

Мы использовали рекомендации статьи, чтобы собрать отчёт в SCCM о том, где установлены, а где нет последние важные обновления. Это помогло выявить ряд проблем, которые описаны ниже.

3. В продолжение предыдущего пункта. К своему удивлению мы обнаружили несколько систем Windows 7 без SP1! Это объясняло, почему они не устанавливали новые обновления при полном внешнем благополучии. Почему мы не видели проблем на WSUS? Обновления с SP1 были declined в давние времена, чтобы исключить другую проблему — мало места на диске WSUS, а также чтобы искючить установку SP1 через тонкие каналы. В результате эти обновления отсутствовали в отчётах.

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

Что касается установки SP1, то это надолго парализует работу пользователя: установка SP1, а потом сотен обновлений займет многие часы даже на очень быстром компьютере — быстрее переустановить систему с пропатченного образа.

4. Обнаружилось некоторое количество компьютеров-призраков. Если на компьютер не накатываются групповые политики, то на нём не работает должным образом фаервол (не работает пинг, удаленное управление), агенты WSUS и SCCM — в результате компьютер превращается в призрак, в то время как пользователь может на нём спокойно работать с почтой и коммуникатором, которые настраиваются автоматически (вот они издержки автоконфигурирования!). WSUS и SCCM периодически вычищают свои базы от компьютеров, которые долго не шлют отчёты (60-90 дней обычно). Коммерческие антивирусы поступают также. В результате эти компьютеры исчезают из отчётов и превращаются в призраков. Как их обнаружить? Это можно сделать по учётной записи компьютера в AD и по полю последнего обновления пароля, а также по DNS: по умолчанию настройки таковы, что компьютер должен обновлять запись в DNS примерно раз в две недели. Но не все так просто, потому что есть отпуска, больничные и редко используемые компьютеры.

Вывод: нужно проверять «призрачность» компьютеров и здоровье агентов (AV, WU, SCCM) на них. Если компьютер отсутствует в SCCM и WSUS, но его учётная запись не просрочена в AD (обновляется запись в DNS), то это скорее всего призрак.

(Отступление. Добавление компьютеров в домен должно выполняться только модерируемым способом через создание компьютерных учётных записей-заглушек, свободное добавление пользователями компьютеров в домен нужно запретить. Удалять учёные записи компьютеров допустимо только после выяснения судьбы физического компьютера.)

5. Обычно политики обновления рабочих станций и серверов различаются. Соответственно используются различные группы WSUS и разные наборы одобренных обновлений. Оказалось, что в серверных контейнерах AD в силу объективных причин располагаются учётные записи некоторых рабочих станций. В результате на них не приезжали обновления клиентских ОС, которые не были одобрены для серверов.

Вывод: контейнер AD всего лишь логическая сущность — в нём может оказаться компьютер с любой ОС — нужно контролировать и применять соответствующие политики и группы WSUS.

6. Поврежденный агент WSUS.

Одна из причин старый клиент CryptoPro, который блокировал работу агента WU. Обновленные версии CryptoPro давно существуют, но раз в несколько месяцев попадается компьютер с такой проблемой, несмотря на жесткие ограничения на установку ПО.

Поврежденная папка c:\windows\SoftwareDistribution. Периодически попадаются компьютеры с такой проблемой. Остановка сервиса WU и удаление папки решает проблему. Иной раз приходится использовать более мощный скрипт восстановления агента WU с перерегистрацией библиотек, но последнее время, как показывает опыт, это редко срабатывает. Чаще всего причина в другом.

Это чаще всего это повреждение образа системы. При этом часть обновлений может ставится, но некоторые застревают намертво. В CBS.log вы можете увидеть ошибки поврежденных файлов. Иногда помогает sfc /scannow. На более новых системах DISM /ScanHealth. Но лучше использовать утилиту sfcfix.exe (можете найти в Интернет). Если она не исправила проблему, то переустановка системы быстрейший путь. Иначе вас ждет шаманство с заменой поврежденных файлов в оффлайн режиме без всяких гарантий.

Вывод: агент WU является критически важным сервисом на рабочих станциях. Нужно следить за его здоровьем (фактический критерий — установка последних обновлений), восстанавливать безотлагательно, а при невозможности — переустанавливать систему.

Реклама

комментария 2

  1. DISM /ScanHealth

    Deployment Image Servicing and Management tool
    Version: 10.0.14393.0

    Error: 87

    The scanhealth option is unknown.
    For more information, refer to the help by running DISM.exe /?.

    The DISM log file can be found at C:\Windows\Logs\DISM\dism.log

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: