Своевременное обновление важнейших серверов

Количество «червей», сценариев сканирования и нападений из Internet не уменьшается, и проблема управления программными исправлениями для сетевых администраторов становится все более актуальной. Руководство по безопасности не может быть полным без рекомендаций по применению исправлений и пакетов обновлений. Но для того чтобы применить новейшие исправления, недостаточно просто посетить сайт Windows Update и загрузить рекомендуемые обновления. Для модернизации рабочих станций и некритичных серверов автоматизированные решения пригодны, но для надежной защиты важных производственных серверов нужны более продуманные методы управления исправлениями. Приемы, изложенные в данной статье, подходят не для всех организаций, но администраторы, готовые потратить время и усилия на углубленную работу с исправлениями, будут вознаграждены высокой стабильностью и безопасностью инфраструктуры предприятия.

Проверка сигнатур

Иногда из-за особенностей политики безопасности сервера администраторы получают предупреждение о недействительности сигнатуры файла при установке исправления. Однако представители Microsoft уверяют, что все исправления снабжены подписями. Отчего же возникают подобные предупреждения?

Причина недоразумения связана с тем, что существует два типа сигнатур: Authenticode и Windows Hardware Quality Labs (WHQL). Разработчик программы удостоверяет подлинность файла, дополняя его сигнатурой Authenticode. Windows не выполняет автоматической проверки сигнатур Authenticode при установке исправлений. Проверить сигнатуру можно, щелкнув правой кнопкой мыши на файле и выбрав пункт Properties. Это можно сделать и с помощью запускаемого из командной строки инструмента Chktrust, поставляемого в составе пакета разработки SDK Microsoft Platform. Chktrust.exe сообщает, что сертификат действителен, но не раскрывает имени владельца.

Сигнатура WHQL хранится в особом файле каталога, она свидетельствует о том, что компания Microsoft протестировала файл драйвера на совместимость с Windows XP или Windows 2000. Все файлы драйверов в исправлении снабжены сигнатурами WHQL. Предупреждение на экране появляется, когда сигнатура для файла драйвера не совпадает с хранящейся в файле каталога.

Почему же выдается предупреждение, если сигнатура Authenticode проверяется перед установкой исправления, а сигнатура WHQL драйвера — после установки исправления? Дело в том, что новые файлы исправления разворачиваются с новыми сигнатурами WHQL. Поскольку новые сигнатуры WHQL до завершения установки недоступны, Windows не может проверить новые сигнатуры до тех пор, пока исправление не установлено. Проверить эти сигнатуры можно с помощью инструмента Windows File Signature Verification (sigverif.exe) после установки исправления. Если проверить сигнатуры Authenticode до установки и запустить Sigverif для проверки сигнатур WHQL после установки, то предупреждение о недействительной сигнатуре можно спокойно игнорировать.

Проверка файлов

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

Получить список файлов исправления можно вручную, извлекая их с помощью ключа /x. Например, следующая команда извлекает файлы из исправления q123456.exe:

q123456.exe /x

Недокументированная функция ключа /x позволяет извлекать файлы по определенному пути. При использовании /x в сочетании с ключом /q файлы извлекаются без участия пользователя, и процедуру можно автоматизировать с помощью сценариев. Например, следующая команда извлекает файлы из исправления q123456.exe в каталог C: emp:

q123456.exe /x:c: emp/q

Администратор может увидеть извлеченные файлы и их свойства. Сделать это проще, если воспользоваться составленным мною сценарием hfinfo.vbs. Исправления для Windows Server 2003 упакованы иначе, поэтому данный сценарий работает только с Windows 2000. Сценарий извлекает файлы исправления и показывает дату, время, размер и версию каждого файла. Hfinfo.vbs запускается командой

cscript.exe hfinfo.vbs

где HotfixFilename — имя файла исправления. Зная, какие файлы и версии файлов устанавливаются, проще обнаружить потенциальные конфликты и другие неполадки. Но самое главное — станет известно, какие файлы будут развернуты на сервере.

Отслеживание порядка установки

Исправления Windows NT 4.0 должны разворачиваться в строго хронологическом порядке. В Windows 2000 и более поздних версиях процесс установки исправлений был усовершенствован и дополнен обновленным механизмом проверки версий. Кроме того, Microsoft выпустила инструмент Qchain (предоставляется по адресу http://www.microsoft.com/downloads/ details.aspx?displaylang=en&familyid=a85c9cfa-e84c-4723-9c28-f66859060f5d), с помощью которого можно установить несколько исправлений без необходимости перезагрузки системы после каждой установки. Однако в некоторых ситуациях по-прежнему требуется соблюдать порядок установки исправлений.

Если нужно изменить файл, задействованный в работе, то в реестр вносится запись, которая указывает операционной системе на необходимость замены файла при следующей перезагрузке. При установке нескольких исправлений один и тот же файл может быть обновлен несколько раз. В этом случае qchain.exe проверяет, действительно ли только самая новая версия файла отображается в списке развертываемых исправлений. Следует всегда запускать qchain.exe перед установкой нескольких исправлений.

Однако утилита qchain.exe не безупречна, так что может быть инсталлирована и более старая версия файла. Например, файлы некоторых типов, такие как .asp и .chm, не содержат встроенной информации о версии. Кроме того, qchain.exe работает только с теми файлами, которые используются Windows и не могут быть заменены до перезагрузки. Если файл может быть заменен немедленно, то qchain.exe «не видит» его.

Чтобы избежать такой ситуации, следует по возможности разворачивать исправления в хронологическом порядке. Однако этот порядок не всегда известен. Его нельзя точно установить по номеру бюллетеня безопасности или номеру статьи в базе знаний Knowledge Base. Порядок можно установить по дате выпуска, но единственный абсолютно надежный способ выяснить правильный порядок установки — проверить версии и даты каждого файла в исправлении.

Полностью автоматическая установка

Вместе с пакетом Windows 2000 Service Pack 3 (SP3) компания Microsoft предложила службу Automatic Updates, которая автоматически отслеживает, загружает и по желанию пользователя устанавливает обновления Windows. Эта служба — огромный шаг вперед в деле обеспечения безопасности Windows, но ее недостатки не позволяют полагаться исключительно на автоматические процедуры.

Во-первых, не все бюллетени безопасности связаны с установкой исправлений. Например, в бюллетене Microsoft Security Bulletin MS02-064 (Windows 2000 Default Permissions Could Allow Trojan Horse Program) речь идет о принимаемых по умолчанию полномочиях NTFS для корневой папки системы, и исправления в нем нет. Администратор должен вручную изменить полномочия на каждом сервере. Служба Automatic Updates не поможет внести эти и другие исправления, требующие вмешательства администратора.

Привыкнув пользоваться службой Automatic Updates, легко забыть о необходимости читать бюллетени безопасности Microsoft. В этих бюллетенях содержится полезная информация, в том числе рекомендации, как избежать проблемы или смягчить ее, даже без исправления. Если процесс применения исправлений на предприятии автоматизирован, то администратору необходимо следить за бюллетенями в поисках ручных исправлений.

И наконец, служба Automatic Updates не всегда справляется со сложными особенностями исправлений. Некоторые исправления необходимо проводить в особых условиях, требующих тщательного анализа перед установкой. Из-за этих ограничений Automatic Updates будет удобной службой распространения, но не заменит внимательного изучения бюллетеней безопасности.

Двойной контроль

Даже если были соблюдены все рекомендации, иногда приходится устанавливать исправления повторно. Например, администратор выполнил все загрузки по Automatic Updates, а затем обнаружил на сайте Windows Update другие обновления. Но после установки всех этих исправлений и запуска инструмента HFNetChk выясняется, что нужно разворачивать еще несколько исправлений. Администратор запускает qfecheck.exe, чтобы проверить, все ли исправления установлены корректно, затем применяет Microsoft Baseline Security Analyzer (MBSA) и обнаруживает, что одно из исправлений развернуто неверно.

В чем причина неполадок? Отчасти проблема возникает из-за того, что Microsoft использует для исправлений много разных программ установки. Например, пиктограммы и соглашения об именовании исправлений Microsoft Internet Explorer (IE) — иные, чем у исправлений Windows 2000. В некоторых продуктах используется программа установки Microsoft, Windows или Systems Management Server (SMS), а в других, таких как Microsoft Office, — совсем другая программа. С появлением пакета SP3 даже исправления Windows 2000 стали разворачиваться с помощью установщика update.exe вместо hotfix.exe. Трудно предугадать, как поведет себя каждый из множества инсталляторов в конкретных условиях.

Причиной неполадок могут быть последовательность установки, порча файлов и даже запуск System File Checker. Подробнее о проблемах, связанных с System File Checker, рассказано в статье Microsoft «The SFC /SCANNOW Command May Overwrite Hotfix Files» по адресу http://support.microsoft.com/?kbid=814510. Кроме того, ошибки возникают в процессе установки операционной системы вместе с пакетами исправлений, из-за невнимательности оператора, неправильного определения версий и ограниченного охвата продуктов.

Другая сторона проблемы — существование множества инструментов для проверки имеющихся исправлений, у каждого из которых есть свои достоинства и недостатки. В разных инструментах используются различные сочетания способов определения исправлений и корректности их установки. Чтобы определить, было ли установлено исправление, инструмент может проверить реестр, версии файлов или сигнатуры файлов. Но из-за множества факторов, затрудняющих определение версии, эта процедура далека от совершенства. Например, при установке на сервере пакета обновлений вместе с операционной системой версия продукта может быть зарегистрирована иначе, чем при установке пакета обновлений после операционной системы.

Мое решение — проверить исправления, затем сделать это еще раз с помощью другого инструмента. В табл. 1 приведен список бесплатных продуктов для проверки исправлений.

Другие обновления

К сожалению, при установке исправлений можно забыть о других обновлениях, которые необходимо использовать. Например, большинство инструментов проверки исправлений сообщают, какие исправления требуются для данного пакета обновлений, но не всегда информируют пользователя о наличии нового пакета обновлений. Кроме того, Windows Update охватывает только основные продукты Microsoft. В табл. 2 приведено несколько исправлений, которые администраторы часто пропускают. Многие программы управления исправлениями от независимых поставщиков имеют гораздо более широкий охват продуктов, чем инструменты Microsoft. В табл. 3 приведено несколько инструментов управления исправлениями производства независимых компаний.

Когда требуется повторная установка?

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

  • после добавления или удаления компонентов Windows;
  • после аварийных работ;
  • после восстановления с резервной копии;
  • после установки пакета обновлений.

В определенный момент перед выпуском пакета обновлений компания Microsoft должна «заморозить» исходный текст для тестирования. Во время периода испытаний Microsoft устраняет ошибки в пакете обновлений и выпускает новые исправления. Компания часто повторно публикует эти исправления (называя их постпакетными исправлениями — post-service pack hotfixes) при выпуске пакета обновлений. После установки нового пакета обновлений полезно повторно установить постпакетные исправления. Я также рекомендую регулярно проверять машины с помощью автоматизированной программы управления исправлениями, чтобы убедиться, что все исправления корректно развернуты и представлены новейшими версиями.

Следите за новыми исправлениями

Было время, когда Microsoft рекомендовала устанавливать только самые необходимые исправления. Отказ от установки всех исправлений на корректно функционирующем сервере был общепринятой практикой. Но с увеличением числа атак из Internet положение изменилось.

Несмотря на ряд исключений, в нынешних условиях лучше всего устанавливать все исправления и пакеты обновлений на серверах, которые выполняют важные задачи или требуют высокого уровня безопасности. Microsoft предполагает, что пользователи разворачивают новейшие пакеты обновлений, и некоторые исправления несовместимы со старыми пакетами обновлений. Для некоторых исправлений необходимы DLL, выпущенные в составе новых пакетов обновлений, а неверные версии файлов могут привести к нестабильности сервера. Таким образом, перед каждым обновлением необходимо провести тщательное тестирование.

Еще один фактор, который следует учитывать перед применением исправлений, — быстрота реакции. Иногда для защиты сервера необходимо устанавливать исправления сразу после тестирования в конкретной среде. Если взломщик действительно стремится проникнуть в Web-узел, ему нужно лишь внимательно следить за бюллетенями Microsoft и отыскивать уязвимые места, прежде чем администратор установит нужное исправление. Единственный надежный способ защиты — как можно быстрее применять исправления на серверах. Кроме того, обязательно следует использовать другие инструменты, такие как брандмауэры, системы обнаружения несанкционированного доступа (Intrusion Detection Systems, IDS) и программу URLScan, чтобы блокировать известные нападения.

Где получить помощь?

Раньше в статьях Microsoft встречалось предупреждение, что исправления не относятся к числу поддерживаемых компанией продуктов, и подчеркивалось, что исправления, как правило, не проходят такого же исчерпывающего тестирования, как пакеты обновлений. Но положение изменилось, и сегодня Microsoft предоставляет бесплатные консультации по проблемам, связанным с исправлениями. Как связаться со службой Microsoft Product Support Services (PSS), можно узнать по адресу http://support.microsoft.com/default.aspx?scid=fh;enus;cntactms.

Кроме того, Microsoft предоставляет консультации через тематические конференции. Этот способ бывает очень эффективен, так как в конференциях публикуются сообщения не только Microsoft, но и членов сообщества Windows. Полный список конференций, в которых можно найти информацию по безопасности, опубликован по адресу http://www.microsoft.com/technet/newsgroups/ nodepages/security.asp. Microsoft предоставляет поисковый механизм для этих групп, но лучше воспользоваться поисковым механизмом Google для Usenet, который охватывает и тематические конференции Microsoft.

Существуют и другие общедоступные форумы и списки рассылки. Ответы на вопросы по управлению исправлениями можно найти на сайте http://www.patchmanagement.org. Два самых больших списка рассылки по проблемам безопасности, связанным с Microsoft, — FOCUS-MS по адресу http://www.securityfocus.com/archive/88 и NTBugtraq по адресу http://www.ntbugtraq.com.

В сфере управления исправлениями остается множество нерешенных проблем, и пройдет немало времени, прежде чем можно будет целиком довериться автоматизированным процедурам. Лучший способ работы с исправлениями — своевременно применять их. Одним организациям больше подойдет автоматизированное решение, в других администраторы предпочтут вести собственный список установленных исправлений и полностью владеть ситуацией. Следите за информацией на общедоступных форумах и тщательно тестируйте исправления перед тем, как применять их. Следуя приведенным выше рекомендациям, вы сможете максимально надежно защитить важнейшие серверы предприятия.

Марк Барнетт (mburnett@xato.net) — независимый консультант по безопасности и автор статей, связанных с безопасностью IIS