 |
|
|
|
Уязвимости в MS Windows. В поисках решения проблемы по SUSекам Microsoft
Уязвимости в MS Windows. За последнее время значительно участились сетевые атаки, проводимые через Интернет, причем их успешность в подавляющем числе случаев обусловлена вовсе не выдающимися способностями атакующих. У многих в памяти еще свежи воспоминания о лихорадке, вызванной уязвимостью в MS SQL Server 2000, или недавней эпидемии червя W32.blaster, эксплуатирующего уязвимость в службе RPC/DCOM. Масштаб этих атак был коллосален, даже не смотря на то, что в обоих случаях Microsoft заранее выпустила обновления, закрывающие найденные уязвимости. В этой статье будут рассмотрены различные способы автоматизации процесса установки критических обновлений для ОС MS Windows (2000/XP/2003). Программные уязвимости и методы борьбы с ними Как известно, программы пишутся людьми. Так было всегда – и в незапамятные времена мейнфреймов, и на заре появления первых ПК, да и сейчас ситуация принципиально не отличается от того, что было 10 лет назад. Конечно, появляются новые методологии, создаются новые языки программирования, но программы по-прежнему пишутся людьми, и в ближайшее время, видимо, здесь ничего революционного не произойдет. Ни для кого не секрет, что людям свойственно ошибаться. Ошибаются все – от школьника, делающего свои первые шаги в Паскале, до матерого программиста, пишущего модули ядра ОС. Но если ошибки школьника, кроме его учителя и самого школьника, мало кого волнуют, то проблемы в часто используемых сервисах сетевых ОС волнуют значительно большее число людей. У многих в памяти еще свежи воспоминания о W32.blaster, всемирной лихорадке с червем Slammer, эксплуатирующим уязвимость в сервере MS SQL Server, проблемах с безопасностью веб-сервера MS IIS (червь Code Red), службах ftp и sendmail для Linux, и уязвимостях в MS Internet Explorer. Причем опыт показывает, что во многих случаях проблем, вызванных этими уязвимостями, можно было полностью избежать. Так, исправления для RPC/DCOM были опубликованы на Windows Update за несколько недель до начала эпидемии, исправление, закрывающее уязвимость в MS SQL Server было доступно для скачивания в течение нескольких месяцев, не говоря уже о регулярно появляющихся «заплатках» для Internet Explorer и Outlook Express. Обновления для популярных Linux-программ тоже появляются достаточно быстро. Итак, своевременная установка обновлений избавляет нас от множества проблем. И все было бы хорошо, если бы здесь не вмешивался человеческий фактор. Ведь для того, чтобы установить обновление, нужно сначала узнать о том, что оно появилось (здесь нам могут помочь всевозможные bug-листы), найти его на сайте производителя, скачать и установить на все машины, подверженные данной уязвимости. Не удивительно, что времени на выполнение этих работ очень часто не хватает, что и подтверждается историей вирусных атак последних лет. Еще одно свидетельство тому – инициатива, озвученная генеральным директором компании Microsoft Стивом Балмером после летней эпидемии W32.blaster об обязательном интегрировании средств автоматического обновления в следующие версии операционной системы MS Windows. Однако это будет в будущем, и пока оно не наступило, нам – системным администраторам – придется самостоятельно искать решения одной из самых важных административных проблем, а именно – как наиболее быстро и с минимальными усилиями устанавливать обновления для используемых программ? И хотя рынок программных продуктов, решающих данную проблему, еще молод, уже сейчас на нем присутствует достаточное количество различных игроков, предлагающих свои решения проблемы оперативного обновления. Не является исключением и компания Microsoft, предлагающая широкий спектр продуктов, направленных на решение проблем своих клиентов. Остановимся более подробно на одном из них – Microsoft Software Update Services. Концепция SUS Существует мнение, что на компьютеры, полностью изолированные от Интернета, обновления в принципе можно и не устанавливать, решая проблемы несанкционированного доступа административно. Однако для компьютеров, хотя бы изредка появляющихся в Сети, регулярная установка обновлений абсолютно необходима. Именно для этого в состав еще Windows 2000 был включен компонент «Автоматическое обновление». При подключении компьютера к Сети этот компонент автоматически связывается с узлом Windows Update, определяет, какие критические обновления системы доступны для установки и скачивает их. Этот подход вполне применим для домашнего компьютера с 56К dialup-подключением. Однако для организаций это практически не применимо, так как большинство организаций оплачивают трафик помегабайтно и расходы от многократно скачанного обновления (пропорционально количеству компьютеров) никак не обрадуют начальство. Здесь нам на помощь приходит SUS. Скачивая обновление один раз, он выступает в качестве корпоративного сервера Windows Update, тем самым минимизируя внешний оплачиваемый трафик. Кроме того, SUS является масштабируемым решением, то есть существует возможность построить иерархию SUS-серверов для распределения нагрузки или для «адресной» установки обновлений. Так, при помощи иерархической схемы можно сначала проверить работу обновлений на тестовой зоне, а затем разрешить установку в рамках всего предприятия.
Системные требования Требования к необходимому оборудованию во многом определяются тем, как именно планируется использовать SUS. Если нужно обеспечить установку обновлений в небольшой локальной сети, то вполне можно ограничиться минимальными требованиями, заявляемыми Microsoft – 700 МГц процессором, 512 Мб ОЗУ и парой гигабайт свободного места для хранения скачанных обновлений. Однако если вы собираетесь делать многоуровневый корпоративный узел обновлений, то требования могут быть гораздо выше и должны определяться в зависимости от поставленной задачи. С точки зрения устанавливаемого программного обеспечения системные требования более универсальны. Независимо от масштабов, для установки SUS необходимо наличие веб-сервера MS IIS 5.0/6.0 и обозревателя MS Internet Explorer версии не ниже 5.5. Устанавливаем SUS Здесь все не сложнее, чем с любым другим продуктом от Microsoft, за исключением того, что при установке не нужно заполнять различные регистрационные формы и думать об активации – продукт бесплатен. Так что просто качаем SUS с сайта Microsoft и запускаем инсталлятор. При установке SUS автоматически устанавливается утилита IIS Lockdown, которая, в принципе, может нарушить работу других приложений, выполняющихся на этом же веб-сервере. Хорошо было бы установить SUS на машину, на которой хотя бы не выполняется других веб-приложений, а еще лучше – на специально выделенный компьютер, особенно если количество обслуживаемых SUS-клиентов велико. Настраиваем SUS Итак, сервер SUS установлен, и теперь можно приступить к его настройке. SUS представляет собой веб-приложение на языке ASP для веб-сервера IIS, так что не удивительно, что его настройка полностью осуществляется через веб-интерфейс. Для того, чтобы открыть страницу настройки SUS, можно либо воспользоваться ярлыком «Microsoft Software Update Services», расположенным в меню «Administrative tools», либо просто написать в браузере: http://localhost/SUSAdmin. После этого мы увидим примерно следующее:
Все основные настройки определяются в пункте «Set Options».Здесь мы можем задать настройки http-прокси, выбрать языки ОС, для которых необходимо иметь обновления на нашем сервере, а также определить настройки синхронизации нашего сервера. SUS – решение масштабируемое, поэтому в качестве источника обновлений может выступать либо корневой узел Windows Update, либо другой SUS-сервер. Второй вариант может использоваться в крупных организациях с большим числом обслуживаемых клиентов, в то время как нам вполне хватит и первого. Итак, сохраним наши настройки и перейдем в раздел «Synchronize». В этом разделе находится все, что связано с синхронизацией нашего сервера с узлом обновлений верхнего уровня: задание расписания, просмотр журнала и «ручная» синхронизация. После нажатия на «Synchronize now» SUS автоматически соединится с корневым узлом и загрузит все необходимые обновления. Первая синхронизация может продлиться долго, ведь, скорее всего, серверу придется загрузить довольно большее количество обновлений с корневого сайта, однако все последующие синхронизации будут проходить гораздо быстрее, загружая только свежие обновления. После загрузки обновлений необходимо определить, какие из них будут доступны для автоматической установки. Для этого перейдем в раздел «Approve Updates», отметим необходимые нам обновления и нажмем на кнопку «Approve». На этом серверную часть в целом можно считать настроенной, и теперь самое время перейти к настройке клиентской части. Устанавливаем клиентов Windows Update Для работы с SUS необходим клиент Windows Update версии не ниже 2.2, который уже присутствует в Windows 2000 SP3, Windows XP SP1 и Windows 2003. Однако, если у вас используется более старая версия Windows, не содержащая в себе клиента нужной версии, то его нужно установить отдельно, используя установочный пакет wuau22.msi с сайта http://www.microsoft.com. Для этого можно либо воспользоваться возможностями централизованной установкой ПО через групповые политики (технология IntelliMirror), либо установить пакет вручную, в случае если машины не объединены в домен. Настраиваем клиента Windows Update Все настройки клиента Windows Update хранятся в реестре Windows и считываются им каждый раз при запуске службы «Automatic Updates». Для задания этих настроек можно либо вручную отредактировать реестр, либо задать необходимые значения при помощи групповых политик. Реестр Минимально необходимые для работы SUS настройки хранятся в следующих ключах реестра: HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdate WUServer=”http://<Имя сервера SUS>” WUStatusServer=”http://<Имя сервера SUS>” HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdateAU UseWUServer – использовать (1) или нет (0) SUS-сервер. Этих параметров уже достаточно для того, чтобы клиент автоматического обновления начал работу с нашим сервером, однако для более тонкой настройки нужно определить еще несколько ключей: HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdateAU ScheduledInstallDay – позволяет задать день недели (0-7), в который будет осуществляться установка. ScheduledInstallTime – час (1-24), в который будет осуществляться установка. AUOptions – выбор режима установки (2 – уведомить о доступных уведомлениях, 3 – скачать и уведомить перед установкой, 4 – скачать и установить согласно расписанию). NoAutoUpdate – 1 – включить автообновление, 0 – выключить. RescheduleWaitTime – этот ключ используется в случае, если клиент не смог установить обновление в заданное время. Задает время в минутах (1-60), в течение которого будет предпринято следующее обращение к серверу. NoAutoRebootWithLoggedOnUsers – 1 – пользователь может отменить перезагрузку, вызванную обновлением. Для редактирования реестра на удаленных машинах можно воспользоваться стандартной утилитой reg.exe, входящей в Windows XP/2003 и ResourceKit для Windows 2000. Для ее работы необходимо, чтобы на удаленной машине была запущена «Служба удаленного управления реестром» и пользователь, под которым будет производиться подключение к компьютеру, имел права на запись значений в соответствующие ключи реестра. Однако на практике эти требования далеко не всегда бывают выполнимы, поэтому более целесообразно использовать домен и групповые политики. Групповые политики Групповые политики являются универсальным средством администрирования компьютеров, входящих в Windows 2000/2003 домен. Они позволяют достаточно гибко настраивать как отдельные машины, так и несколько машин, объединенных в группы безопасности или размещенных в организационных единицах. Это достигается привязкой групповых политик к организационным единицам и редактированию их параметров безопасности. Используя групповые политики, можно быстро настроить клиента автоматических обновлений, как на тестовой группе машин, так и на всех машинах, входящих в домен. Кроме того, можно определять различные настройки для различных организационных единиц домена. Для настройки клиента автоматического обновления с помощью групповых политик можно использовать стандартный для Windows 2003 Server административный шаблон wuau.adm. Для Windows 2000 Server этот шаблон может быть загружен с сайта Microsoft. Настройка производится заданием соответствующих значений политик компьютера, расположенных по следующему пути: «Computer Settings –> Administrative Templates –> Windows Components –> Windows Update».
Здесь при помощи стандартного редактора групповых политик можно легко и просто настроить все то, что выше мы задавали через реестр. Согласитесь, этот способ гораздо проще, однако для него нужен Windows 2000 домен. Читаем журналы При своей работе система автоматического обновления ведет журналы в нескольких местах: на SUS-сервере, на каждом клиенте и в системном журнале. Некоторые из них могут быть очень полезны при мониторинге работы системы (системный журнал, журнал на клиенте), а некоторые (журнал веб-сервера IIS) просто незаменимы при настройке прав доступа к SUS-серверу, а также при обычном мониторинге его работы. Итак, рассмотрим более подробно что, где и когда создается. На стороне клиента Каждый раз при обновлении системы клиент Windows Update добавляет в файл %windir%Windows Update.log записи следующего вида:
В этом файле подробно журналируются все действия клиента. Содержимое этого файла достаточно прозрачно и скорее всего не вызовет проблем в понимании. Кроме того, в папке c:Program FilesWindowsUpdate в файле uihist.xml хранится история установки всех обновлений для данной машины. В системном журнале появляются события, содержащие информацию о работе клиента:
Эта информация может быть полезна при мониторинге работы системы обновлений, особенно если используется какая-нибудь система централизованного мониторинга журналов событий. На стороне сервера Так как SUS работает на IIS, то все сообщения, касающиеся его работы, нужно искать в журналах IIS. По умолчанию, журнал IIS находится в %SYSTEMROOT%LogFilesW3SVC1, его файлы называются по текущей дате и с установленным SUS содержат записи следующего вида:
Посмотрим на эту строчку более подробно. Смысл первых двух полей достаточно очевиден. Третье поле показывает IP-адрес клиента, который обратился к серверу, в четвертом поле указывается IP-адрес сервера, пятое – порт, на который было обращение, шестое – метод HTTP запроса клиента (GET, POST, HEAD, PUT, DELETE и т. д.), седьмое указывает файл, к которому обратился клиент, восьмое – http-код, который вернул IIS. Если IIS сконфигурирован правильно, то возвращаемый им код всегда будет равен 200. Девятое поле идентифицирует клиента Windows Update. Если все сконфигурировано правильно, то в журнале IIS будет примерно следующее:
Здесь мы видим, как клиент с IP-адресом 192.168.10 успешно загружает обновления с SUS-сервера. Процесс их установки можно отследить либо по системному журналу, либо по лог-файлу на клиенте. Инициируем подключение клиента На первых этапах, когда производится настройка системы, для проверки правильности настроек довольно часто возникает необходимость принудительно инициировать обращения клиента к серверу. По умолчанию клиент Windows Update производит обращение один раз за 17-22 часа и для того, чтобы инициировать «внеплановое» подключение, приходится вооружаться известным ударным инструментом и осуществлять некоторые шаманские действия:
В течение некоторого времени (обычно это 5-10 минут) клиент предпримет очередную попытку загрузить обновления, отследить которую можно по содержимому следующего ключа реестра: HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionWindowsUpdateAuto Update Значение DetectionStartTime этого ключа хранит время последнего обращения к серверу обновлений. Необходимо отметить, что этот способ применим только для компьютеров, настройка клиентов которых проводилась с помощью редактирования реестра. Дело в том, что при использовании групповых политик опция, включающая и отключающая клиента, недоступна, пока к машине применяется групповая политика, конфигурирующая автоматические обновления. Таким образом, для того чтобы инициировать цикл обновления, необходимо либо отключить политику, определяющую настройку Windows Update, либо перенести машину в другую организационную единицу, к которой эта политика не применяется. После этого нужно применить новые политики и, отредактировав настройки клиента, инициировать обращение к серверу SUS. Для применения групповых политик в случае Windows 2000 можно воспользоваться программой secedit, в случае Windows XP/2003 – gpupdate. Если не хочется разбираться с синтаксисом этих команд, можно просто перезагрузить компьютер. Завинчиваем гайки, включаем https Как мы уже видели выше, интерфейс администрирования SUS-сервера по http доступен локальному администратору сервера сразу после установки. Однако иногда бывает необходимо администрировать некоторые службы (компоненты) сервера удаленно, либо в рамках все той же локальной сети, либо через Интернет. В случае SUS это совсем просто, т.к. его администрирование уже осуществляется через веб-интерфейс и ничто не мешает нам сделать его общедоступным, настроив соответствующим образом IIS. С точки зрения элементарной безопасности, настраивая удаленное администрирование в IIS, следует соблюдать несколько простых правил:
Для выполнения этих требований вам понадобится сертификат для веб-сервера IIS, получить который можно, создав свой собственный центр сертификации с помощью средств Windows Server 2000/2003. Для разрешения административного доступа по https необходимо в настройках безопасности каталога веб-сервера IIS включить опцию «Требуется безопасный канал (SSL)» для следующих каталогов: autoupdateadministration autoupdatedictionaries Shared ContentEULA ContentRTF Также настоятельно рекомендуется включить опцию «Требуется 128-разрядное шифрование». Это позволит обеспечить достаточную безопасность при передаче пароля через Интернет. Будущее SUS К слову сказать, SUS 1.0 является «бюджетным» решением, позволяющим организовать автоматическую установку только критических обновлений ОС Windows 2000/XP/2003. С его помощью нельзя устанавливать обновления для других программных продуктов, в том числе и от Microsoft. Специально для этих целей Microsoft предлагает (уже не бесплатно) отдельный продукт – System Management Services, позволяющий решать более широкий спектр административных задач, в том числе и установку обновлений для любых программ. Однако, по всей видимости, Microsoft не собирается ставить крест на бесплатном SUS. Так, в первой половине 2004 года на рынок будет выпущен SUS версии 2.0. По предварительной информации от самой Microsoft (на момент написания этих строк продукт еще находился в стадии бета-тестирования) одним из самых значимых нововведений в следующей версии будет переход от обновления только операционной системы Windows к обновлению разнообразных приложений от Microsoft (SQL Server, Office, Exchange и другие). Для этого компанией Microsoft буден создан специальный сайт, содержащий все обновления для ее основных продуктов – Microsoft Update. Кроме того, в SUS 2.0 будет реализован более полный контроль над процессом установки обновлений, произойдет уменьшение размеров скачиваемых заплаток (технология Delta patching), а также появится возможность полного отката установленного патча (Windows Installer 3.0). Так что ждем SUS 2.0. Огромное спасибо за помощь в написании статьи Дмитрию Косинову. Используемые материалы: Обзор рынка ПО для обновлений St. Bernard Software UpdateExpert (http://www.stbernard.com) Поддерживает: Microsoft Windows NT/2000/XP, IIS, SQL Server, Exchange Server, IE, Outlook Express, Windows Media Player, Windows Media Services, NetMeeting, Microsoft Office, MDAC, ISA Server. Особенности:
Созданный с ориентацией на крупные организации, этот продукт поддерживает Active Directory и позволяет удобно работать с большими массивами компьютеров. Примечательная особенность UpdateExpert – возможность работы с конечными машинами без установки агента на них. Shavlik HFNetChkPro (http://www.shavlik.com) Поддерживает: Microsoft Windows NT/2000/XP/Server 2003, Exchange, SQL Server, Outlook, Microsoft Office, Java Virtual Machine, Internet Explorer, IIS, Windows Media Player, Microsoft Data Access Components (MDAC), ISA Server, Commerce Server, .NET Framework. Особенности:
Продукт, ориентированный в первую очередь на обновление программам от Microsoft. К сожалению, работой с ними он в основном и ограничивается. Компания представляет также урезанный бесплатный вариант программы – HFNetChkLT. Ecora Patch Manager (http://www.ecora.com) Поддерживает: Sun Solaris, Windows NT/2000/XP/2003, MS-SQL Server, MSDE, Exchange 5.5 & 2000, Office 2000/XP, Windows Media Player, IE, IIS, MDAC. Особенности:
Схожий по функциональности с HFNetChkPro, этот продукт обладает встроенным планировщиком заданий и гибкой системой оповещения о появлении в базе новых обновлений, удачном сканировании и подобных событиях. Patch Manager является кросс-платформенным решением, не ограничиваясь только платформой Windows. PatchLink Update (http://www.patchlink.com) Поддерживает: Microsoft Windows NT/2000/XP/Server 2003, Unix, Linux, NetWare. Особенности:
Продукт поддерживает большое число систем и обладает довольно удобным интерфейсом управления. Однако могут возникнуть некоторые трудности в его установке. |
МИХАИЛ ПЛАТОВ
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
