Ошибки в программном обеспечении — неотъемлемая часть процесса его разработки и настоящее проклятие всех поставщиков. Даже в тех случаях, когда к проекту подключаются лучшие специалисты, число ошибок увеличивается пропорционально объему кода. В результате хакеры находят множество возможностей для взломов.
Обязанность своевременно вносить оперативные исправления в систему Windows ложиться тяжким бременем на сотрудников ИТ-подразделений. Эти коррективы появляются на свет столь часто, что специалисты по информационным технологиям уподобляются сегодня рабочим-дорожникам, вынужденным постоянно латать дорожное полотно на участке автострады с интенсивным движением. Тем, кто хочет надежно защитить свою сеть, неизбежно придется осуществить целый ряд мероприятий. Нужно разработать схему действий, касающихся таких аспектов работы, как поиск слабых мест программного обеспечения, определение степени угрозы для сети, оценка уровня риска, принятие решений относительно того, когда вносить коррективы и, наконец, составление плана внесения этих корректив.
Сведения о пробелах в системе защиты
Оперативные исправления появляются весьма часто, а значит, нужна такая организация работы, чтобы ни одно из исправлений не осталось незамеченным. В СМИ сообщают лишь о тех случаях, где имеется элемент сенсации, — скажем, о широком распространении какого-нибудь нового вредоносного «червя». Но та информация, которая помогает администратору защищать сеть, не может ни обеспечить рост тиража популярных изданий, ни привлечь дополнительных спонсоров для новостных телепрограмм. Иными словами, в этом деле обычные средства массовой информации администратору не помогут.
Куда же в таком случае следует обращаться? Для начала стоит посетить Web-сайт Security Administrator журнала Windows & .NET Magazine (http://www.secadministrator.com). Здесь можно ознакомиться с содержанием разделов Discoveries и Hot News, а также подписаться на бесплатный почтовый бюллетень Security UPDATE и бесплатный же список рассылки Security Alerts. Еще один ресурс, где можно почерпнуть полезные сведения по проблемам безопасности, — это Web-сайт Расса Купера (Russ Cooper) NTBugtraq (http://www.ntbugtraq.com). Данный сайт представляет собой открытый список почтовой рассылки сообщений о предпринятых атаках. Пользователь может назначить пересылку сообщений на свой адрес электронной почты или в общедоступную папку Microsoft Exchange Server. Один из часто используемых мною ресурсов, посвященных слабым звеньям системы безопасности, — выпускаемый институтом SANS Institute ежемесячный дайджест Windows Security Digest (http://www.sans.org/newlook/digests/ntdigest.htm).
Следующий достойный рекомендации ресурс — HotFix & Security Bulletin Service. Он принадлежит корпорации Microsoft и размещается по адресу: http://www.microsoft.com/technet/security/current.asp. Посетители сайта могут искать исправления по названию продукта или по версии пакета исправлений. Как правило, в посвященных проблемам безопасности бюллетенях (Security Bulletins) приводятся технические подробности, содержатся списки часто задаваемых вопросов, соответствующие статьи из базы знаний Knowledge Base и адреса URL рассматриваемых исправлений. Кроме того, усилиями Microsoft создан центр Microsoft Security Response Center (MSRC) специально для исследования проблем, связанных с защитой данных. Более подробно о центре MSRC рассказано во врезке «Microsoft и проблемы безопасности».
Оценка угрозы
После того как стало известно о наличии слабого звена в системе защиты, первым делом следует оценить серьезность проблемы. Чтобы выяснить, к чему она может привести, необходимо обратиться к вышеназванным Web-узлам. Оценивая степень риска, следует учитывать, на что влияет та или иная ошибка и в каких ситуациях она нарушает работу системы. Для получения дополнительной информации об испытывающих воздействие ошибки компонентах я настоятельно рекомендую обращаться к таким источникам, как Microsoft TechNet и Microsoft Developer Network (MSDN).
Затем нужно проанализировать различные участки сети и определить, высока ли степень риска для подключенных к ней систем. Этот этап работы избавит от необходимости тратить время на устранение неполадок, не опасных для сети. К примеру, если специалисты Microsoft разработали исправление для системы Microsoft SQL Server, а в сети компании данная система не используется, разумеется, никаких действий предпринимать не нужно.
Если же слабое звено действительно представляет опасность для компьютеров сети, нужно знать, сколь велика эта опасность. Исправление ошибок в коде сервера Microsoft IIS критично, когда сервер подключен к Internet, и не столь актуально, если это всего лишь внутренний сервер IIS. Необходимо продумать, кто может воспользоваться этой ошибкой и насколько велик будет ущерб в самом худшем случае.
Нередко администраторы оправдывают свое нежелание устанавливать оперативное исправление так: «Я знаю своих пользователей и доверяю им. Никто из них не станет покушаться на безопасность данных». И в самом деле нечасто встречаются пользователи, готовые пуститься во все тяжкие, лишь бы нанести максимальный ущерб сети компании. Но всегда есть риск, что кто-то может причинить вред системе из чистого любопытства или из «спортивного интереса». Задача администратора — оценить, насколько серьезна для компании выявленная угроза и принять соответствующие меры. Например, если система SQL Server выполняется на подключенном к Internet сервере, нужно в первую очередь заняться установкой исправлений для Windows 2000 или Windows NT.
Возможно, стоит создать комиссию по проблемам безопасности — этот орган поможет и оценить слабые звенья защиты данных, и определить дальнейшие действия. Важно позаботиться о том, чтобы активную роль в комиссии играли члены групп по UNIX, по базам данных и сетевым проблемам, а также сотрудники подразделения внутренней безопасности: их опыт, знания и навыки могут очень пригодиться. В полном составе комиссия должна собираться не реже раза в месяц, а специалисты по Windows — еженедельно или раз в две недели.
При выявлении новых угроз комиссия может принимать решения относительно того, какие исправления и в какие сроки следует устанавливать. Реализацию рекомендованных мер следует поручить отдельным группам. При возникновении опасности основой для процедуры принятия решений могут служить этапы, определенные мною в данной статье. Рекомендую на заседаниях комиссии обязательно обсуждать, соответствует ли ожиданиям эффективность процесса анализа проблем безопасности.
Разобравшись с тем, насколько та или иная угроза опасна для компании, нужно решить, когда необходимо заняться ее устранением. Обычно новые бюллетени по вопросам безопасности Windows 2000 появляются на сайте Microsoft несколько раз в месяц. Но есть ли необходимость два или три раза в месяц перезапускать все действующие на предприятии серверы Windows 2000 лишь для того, чтобы укреплять систему безопасности? Ведь перезапуск серверов Exchange и файловых серверов оборачивается простоями и может помешать работе пользователей.
Разумеется, главная задача администратора — обеспечивать безопасность серверов, поэтому вопрос не в том, следует ли устанавливать исправление, а в том, когда это лучше сделать. Нельзя забывать и о том, что, хотя оперативность в устранении слабых звеньев системы безопасности — дело важное, медалями за незамедлительную установку исправлений пока не награждают. Мало того, бывает, что Microsoft отзывает или перерабатывает модули коррекции в связи с обнаруженными проблемами реализации. Лишь с учетом всего сказанного следует принимать решение о сроках установки исправлений. Если опасность велика, исправление следует установить при первой же возможности отключить серверы. Если же дело терпит, лучше подождать, пока Microsoft выпустит очередной пакет исправлений для данной версии операционной системы. Обычно пакеты исправлений включают в себя все касающиеся защиты данных оперативные исправления, разработанные со времени выхода предыдущей версии пакета исправлений.
Как это делается
Модули коррекции Microsoft поставляются в виде готовых к использованию сжатых исполняемых файлов, состоящих из файлов hotfix.exe, hotfix.inf, а также файлов для замены. С помощью файла hotfix.exe исправление устанавливается, а в файле hotfix.inf содержатся инструкции по изменению определенных файлов и параметров реестра в процессе применения исправления. Microsoft выпускает оперативные исправления различных версий для Windows 2000 и NT. Файл hotfix.exe определяет, выпущен ли установленный в системе пакет исправлений ранее, чем устанавливаемая программа оперативной коррекции, а также используется ли в обоих случаях один и тот же язык.
С помощью данного теста файл hotfix.exe может определить, что данное исправление было установлено как часть пакета исправлений предыдущей версии.
Если все благополучно, hotfix.exe установит модернизированную версию кода. Если же пакет исправлений выпущен после того, как было разработано применяемое исправление, процесс установки прерывается. В процессе модернизации файл hotfix.exe создает в системах Windows 2000 и NT раздел реестра HKEY_LOCAL_ MACHINESOFTWAREMicrosoft Windows NTCurrentVersionHotfix Qxxxxxx, где Qxxxxxx — это ссылка на статью Microsoft, связанную с данным исправлением. В среде Windows 2000 упомянутый файл также создает раздел KEY_LOCAL_MACHINESOFTWAREMicrosoftUpdates Windows 2000SPxQxxxxxx, где SPx — версия пакета исправлений.
При загрузке исправлений выяснится, что различным типам исправлений соответствуют разные форматы имен. Например, некоторым исправлениям для NT присваиваются восьмизначные имена, напоминающие название соответствующей атаки (например, исправление, устраняющее возможность атаки Teardrop Attack, называется tearfixi). В именах других исправлений используется ссылка на соответствующую статью из базы знаний Knowledge Base и на аппаратную платформу (например, q123456i). Схему именования исправлений для Windows 2000 понять проще всего; кроме того, эти имена информативны. Такое имя состоит из номера статьи, названия операционной системы, версии пакета исправлений, в который будет включено исправление, аппаратной платформы и языка (например, q294391_w2k_sp3_ x86_en.exe).
Как правило, исправления устанавливают вручную, однако лучше эту операцию выполнять с помощью сценария. Чтобы установить исправление с помощью сценария, нужно использовать ключ -m файла hotfix.exe. На Экране 1 представлены ключи файла hoftix.exe для Windows 2000.
|
| Экран 1. Параметры командной строки для Hotfix.exe |
В среде NT применяются точно такие же ключи. С помощью ключа -x можно извлекать файлы и точно определять, какие файлы обновляет данное исправление.
С установкой исправлений связана одна проблема. Как правило, после применения каждого исправления администратору приходится заново инициализировать систему. Серверы обычно перезапускаются подолгу: это связано с проверками аппаратных компонентов системой BIOS. Если несколько раз выключить и включить один сервер, это не так сложно, но для тех, кто управляет сотнями серверов, перезагрузка оказывается действительно изматывающей процедурой, связанной к тому же с дополнительными простоями. Разработчики Microsoft решили данную проблему в 2001 г., выпустив утилиту Qchain. Это изделие позволяет устанавливать по несколько оперативных исправлений без промежуточных перезагрузок системы. Более подробная информация об утилите Qchain в сценарии для установки нескольких оперативных исправлений содержится во врезке «Работа с утилитой Qchain».
Развертывание
Оперативные исправления кода можно устанавливать вручную, но тех, кому приходится обслуживать множество серверов, такая перспектива вряд ли устроит. Чтобы не тратить время на перемещения от одного сервера к другому, можно использовать протокол telnet. Встроенной службой telnet оснащается Windows 2000; администраторы NT могут воспользоваться средствами telnet, реализованными в Microsoft Services for UNIX (SFU). Кроме того, можно задействовать систему, предназначенную для управления этим процессом. Такие продукты, как Microsoft Systems Management Server (SMS) и UpdateEXPERT компании St. Bernard Software, обеспечивают возможность автоматического развертывания исправлений кода на серверах. Если в распоряжении администратора имеются тестовые серверы, следует начать с установки исправлений на них, а затем провести тестирование исправления.
Каким образом устанавливать исправление, не так важно; главное — максимально упростить этот процесс. Все этапы установки следует согласовывать с комиссией по обеспечению безопасности и с техническими специалистами. Один из элементов плана развертывания — стратегия выхода из аварийной ситуации в случае, если события будут развиваться нежелательным образом. Необходимо позаботиться о том, чтобы в наличии были самые свежие резервные копии содержимого модернизируемых серверов. И всегда нужно документировать каждый этап установки любого вносимого в систему изменения.
Мониторинг
После установки оперативных исправлений следует организовать мониторинг модернизированных серверов на предмет выявления необычных реакций, которые, возможно, вызваны проведенной инсталляцией. Необходимо следить за появлением на сайтах Microsoft и независимых поставщиков сообщений о новых версиях исправлений, а также отчетов о неожиданных проблемах, возникающих в связи с их установкой. В некоторых случаях там рекомендуется удалить исправление.
|
| Экран 2. Каталоги для удаления обновлений, установленных Hotfix. |
Как показано на Экране 2, при установке исправления в корневом каталоге создаются каталоги для удаления типа \%systemroot%$NtUninstallQxxxxx$.
В Windows 2000 и Windows NT большинство исправлений удаляется с помощью оснастки Add/Remove Programs в панели управления. Кроме того, в упомянутых операционных системах исправления можно удалять из командной строки; для этого нужно в каталоге для удаления исправления запустить файл hotfix.exe с ключами -y и -m. Ключ -y обеспечивает удаление корректировки и может применяться совместно с ключом -m, позволяющим выполнять удаление без участия оператора. Для некоторых исправлений процедура удаления не предусмотрена.
Как важно быть готовым
Идет ли речь о серверах или о рабочих станциях, администраторам систем Microsoft следует уделять больше внимания проблемам безопасности. Начать нужно с определения оперативных и надежных источников информации о нарушениях в системе защиты, а затем регулярно обращаться к этим источникам, чтобы всегда «держать руку на пульсе». Координация процесса развертывания исправлений может вызвать затруднения, поэтому желательно как можно быстрее приступить к составлению плана, который поможет облегчить этот процесс. Затем, когда будет поступать информация о новых угрозах безопасности сети, нужно просто действовать в соответствии с этим планом.
ПОЛ НАЙСЕР — старший системный администратор финансовой компании из Чикаго. Специализируется на проектировании, развертывании и автоматизации информационных систем. С ним можно связаться по адресу: paul@niser.com
MICROSOFT и проблемы безопасности
В прессе корпорации Microsoft порядком достается за ошибки в программном коде. И это правильно: число пользователей Windows огромно, и всякое нарушение защиты этой операционной системы имеет поистине глобальный эффект. Сегодня специалисты Microsoft оперативно реагируют на сообщения об обнаруженных ошибках, но надо сказать, что компания не всегда была такой открытой. Еще недавно представителям Microsoft требовалось несколько дней для того, чтобы признать наличие пробелов в системе безопасности, причем часто утверждалось, что ошибки — всего лишь «конструктивные недоработки».
Ныне Microsoft определяет брешь в системе безопасности как недостаток изделия, из-за которого действия взломщика, стремящегося управлять системой пользователя, манипулировать хранящимися в ней данными или присваивать себе те или иные полномочия, невозможно блокировать — даже если изделие применяется должным образом. В Microsoft это определение применяют ко всем ошибкам, сообщения о которых направляются в центр Microsoft Security Response Center (MSRC).
Один из каналов, по которым Microsoft получает сообщения о выявленных ошибках, — это адрес электронной почты secure@microsoft.com. Специалисты Microsoft полагают, что лишь в 1% сообщений, направленных по этому адресу, речь идет о настолько серьезных проблемах, что их следует решать немедленно. В центре MSRC официально приняты процедуры, в соответствии с которыми специалисты реагируют на сообщения об ошибках, поступающие от пользователей. Сотрудники центра MSRC пытаются воспроизвести проблемную ситуацию, а соответствующая группа разработчиков выявляет ее причину. Специалисты Microsoft определяют, как лучше устранить проблему: с помощью дополнительных средств настройки или пакета исправлений либо оперативного исправления. Если решено подготовить оперативное исправление, команда специалистов испытывает его и готовит к развертыванию. Времени на испытания совсем немного, поэтому иногда приходится выпускать повторные исправления. Подробнее принятый в центре MSRC порядок работы описан в документе http://www.microsoft.com/technet/treeview/ default.asp?url=/technet/columns/security/essays/sectour.asp.
Работа с утилитой QCHAIN
Программу qchain.exe корпорация Microsoft выпустила в 2001 г. Эта утилита, выполняемая в средах Windows 2000 и Windows NT, позволяет выстраивать оперативные исправления в «цепочки» (chains), т. е. устанавливать их одно за другим без необходимости повторной инициализации системы в промежутках между инсталляциями. Раньше применение метода «цепочки» было сопряжено с определенными трудностями, поскольку приходилось выстраивать исправления в определенном порядке так, чтобы процедура модернизации не устанавливала на систему файлы более ранних версий. Иначе говоря, проблема была в том, что состояние системных файлов определяло то исправление, которое вносилось последним. Утилита Qchain организует процесс замещения файлов таким образом, что сначала файлы записываются в очередь Pending File Rename в реестре. Qchain анализирует содержимое подраздела Pending File Rename и изо всех имеющихся исправлений выбирает то, где представлены файлы самой последней версии.
В Листинге A показан код, на примере которого видно, как с помощью утилиты Qchain составляются сценарии для развертывания оперативных исправлений. Первые три строки приведенного кода содержат команду на установку трех оперативных исправлений. Ключ -z обеспечивает установку без перезагрузки системы; ключ -m позволяет выполнять установку в автоматическом режиме, без вмешательства администратора; ключ -q предписывает системе проводить инсталляцию в фоновом (quiet) режиме, копируя файлы незаметно для пользователя. Если устанавливать исправления вручную, то, возможно, лучше ключ -q не использовать и наблюдать за установкой исправления.
Четвертая строка сценария запускает утилиту Qchain и указывает файл, в котором будут регистрироваться результаты ее выполнения.
В приведенном образце файл журнала размещается в каталоге Logs на сервере Fschicago; этому файлу присваивается уникальное имя, состоящее из имени компьютера и даты выполнения сценария. Наконец, для локальной перезагрузки машины можно воспользоваться утилитой Shutdown (из комплекта ресурсов Microsoft Windows 2000 Server Resource Kit или Microsoft Windows NT Server Resource Kit). Эта утилита дает возможность использовать ключи /l и /r. Ключ /l позволяет завершать сеанс работы с системой, а ключ /r — выполнять перезагрузку.
Листинг A. Образец кода для установки цепочки оперативных исправлений.
Q296185_W2K_SP3_x86_en.EXE -z -m -q Q285851_W2K_SP3_x86_en.EXE -z -m -q Q285156_W2K_SP3_x86_en.EXE -z -m -q qchain fschicagologs\%computername% _qchainlog_060101.txt shutdown /l /r