Алексей Лукацкий,
руководитель отдела Internet-решений НИП «Информзащита»
luka@infosec.ru

Давайте представим себе ситуацию, с которой, наверное, многие читатели уже сталкивались. Ваш компьютер атакован червем, и в результате "дырявости" почтовой программы Outlook Express или браузера Internet Explorer не только потеряны важные файлы, но и вы сами стали источником дальнейшего распространения червя. Если уязвимости конфигурации (см. врезку "Типы уязвимостей") можно устранить достаточно легко - изменив настройки ПО, то с уязвимостями реализации ситуация немного сложнее. Для их устранения необходимо устанавливать специальные заплатки, называемые в обиходе "патчами" (patch, Service Pack, hotfix и т. п.), которые закрывают обнаруженные разработчиками бреши.

Типы уязвимостей

Существует три класса уязвимостей, отражающих "жизненный цикл" информационной системы.

Уязвимости проектирования. Наиболее серьезный класс дыр, обнаруживаемых и устраняемых с большим трудом. Пример - уязвимость стека протоколов TCP/IP.

Уязвимости реализации. Возникают на этапе реализации в программном или аппаратном обеспечении при внедрении корректного с точки зрения безопасности проекта или алгоритма. Обнаруживаются и устраняются относительно легко.

Уязвимости конфигурации. Возникают в процессе конфигурации. Этот вид, наряду с уязвимостями реализации, - самая распространенная категория дыр.

Велика ли важность?

Согласно исследованиям ФБР (http://www.fbi.gov) и Университета Карнеги-Меллона (http://www.sei.cmu.edu), 98% инцидентов возникает из-за проблемы, о которой ИТ-отдел уже знал, но не устранил. Аналитики Gartner (http://www.gartner.com) считают, что эта цифра чуть ниже - около 90%. Эксперты координационного центра по безопасности CERT (http://www.cert.org) утверждают, что 95% инцидентов, о которых им сообщают, используют уже известные дыры. Можно заметить общую тенденцию - более 90% всех неприятностей, имеющих отношение к компьютерной безопасности, происходит по причине невнимательности администраторов, одна из задач которых и состоит в своевременной защите постоянно обнаруживающихся дыр в корпоративной сети.

Пример с SQL Slammer (http://www.iss.net/issEn/delivery/xforce/alertdetail.jsp?oid=21824) - яркое тому подтверждение. Компания Microsoft выпустила для этого червя заплату еще в июле 2002 г., за полгода до начала эпидемии, но это не помешало ему натворить немалых бед (см. врезку о черве Slammer).

Червь Slammer - маленький, да удаленький

Червь SQL Slammer (он же Sapphire, он же Helkern) использует брешь класса "переполнение буфера" (buffer overflow) в системе безопасности на узлах с установленным Microsoft SQL Server 2000 или его локальным вариантом MSDE (Microsoft SQL Desktop Engine). Размер файла червя - всего 376 байт, и он распространялся по Интернету с угрожающей скоростью. Как описано в техническом отчете CAIDA (http://www.caida.org/outreach/papers/2003/sapphire/sapphire.html), червь удваивал число своих копий каждые 8,5 с и достиг максимальной частоты сканирования - 55 млн запросов в секунду спустя 3 мин после своего "рождения" (для сравнения: червь Code Red "размножался" на два порядка медленнее, удваивая свою популяцию каждые 37 мин). Всего за 10 мин с момента своего "рождения" Slammer нашел 90% своих потенциальных жертв. По данным экспертов, он вызвал замедление работы Интернета на 25%.

Ущерб от деятельности Slammer составил от 0,95 до 1,2 млрд долл. (для сравнения: ущерб от активности CodeRed оценивается в 2,6 млрд долл., вируса I Love You - в 8,8 и Klez - в 9 млрд долл.). Почти столько же средств пришлось затратить на восстановление того, что было повреждено в результате его деятельности. Примечательно, что Microsoft также пострадала от Slammer, несмотря на то, что именно она и разработала "противоядие" от него за полгода до эпидемии.

Самый известный и на первый взгляд самый простой способ защиты от использующих дыры хакеров и червей - установить "заплату" на все уязвимые узлы. Таковы итоги шумного обсуждения (в котором довелось поучаствовать автору) в мае этого года в сети FIDO. Но многие администраторы просто не подозревают, насколько непрост процесс "накладывания заплат" и какие сложности поджидают их при "обычном" обновлении ПО на узлах сети.

"Куда ставить-то?"

Первым делом нужно как-то узнать о выходе того или иного патча. Многие специалисты подписываются на список рассылки производителя используемых в компании систем. Любой серьезный производитель ПО имеет список обновлений своей продукции. Кроме того, эту информацию можно почерпнуть и в специализированных разделах на сайтах разработчиков ПО, например, Oracle (http://otn.oracle.com/deploy/security/alerts.htm), Microsoft (http://support.microsoft.com), Sun (http://sunsolve.sun.com/pub-cgi/show.pl?target=patchpage).

Однако, когда администратор получает уведомление о выходе соответствующей заплатки, перед ним встает вопрос, прозвучавший в фильме "Добро пожаловать, или Посторонним вход запрещен" и вынесенный в подзаголовок. А это весьма нетривиальная задача. Иными словами, необходимо определить все узлы, на которые надо установить данное обновление. Хорошо, если размер сети ограничивается тремя-пятью десятками машин. А если их несколько сотен?

Поэтому самая первая задача управления заплатками (патчами и т. п.) - найти узел, требующий обновления. Для этого есть два способа. Первый - использовать системы инвентаризации сети (табл. 1), которые позволяют идентифицировать операционную систему узла, установленное на нем ПО и т. п. Достоинство такого решения в том, что системы инвентаризации дают администратору возможность всегда быть в курсе того, что происходит на узлах сети, какие программы (с точностью до версии и Service Pack) на них установлены и т. д. Например, в базе системы AssetMetrix одноименной компании содержится информация о 120 тыс. различных приложений от 16 500 производителей. Однако есть и недостаток - на каждый узел необходимо установить программного агента для сбора этой полезной информации (удаленная инвентаризация проводится очень редко).

Таблица 1. Системы инвентаризации сети

Продукт Производитель Сайт
AssetMetrix AssetMetrix http://www.assetmetrix.com
LANAuditor Inventory http://www.lanauditor.com
TSCensus Tally Systems http://www.tallysystems.com
Tivoli Inventory IBM http://www.tivoli.com
Ecora Auditor Suite Ecora http://www.ecora.com

Другое решение для поиска "непропатченных" узлов - использовать сканер безопасности. Отсутствие заплатки - по сути уязвимость, позволяющая злоумышленникам реализовывать свои атаки. Поэтому многие сканеры безопасности обладают возможностями контроля патчей и других обновлений. В России в настоящее время такое ПО представлено, например, достаточно распространенным продуктом Internet Scanner компании Internet Security Systems (http://www.securityscanner.ru) и отечественной разработкой фирмы Positive Technologies (http://www.xspider.ru) - Xspider. Такие сканеры содержат базу заплаток для различных ОС и приложений и сравнивают текущее состояние сканируемого узла со своей базой.

Помимо сканеров безопасности, позволяющих обнаруживать не только отсутствие патчей, но и сотни других проблем защиты, существуют решения, полностью ориентированные на идентификацию необновленных узлов (табл. 2). Таковы, например, Patch Manager от компании Sun или Baseline Security Analyzer и HFNetChk фирмы Shavlik. Эти продукты ориентированы соответственно на ОС Solaris и Windows и распространяются бесплатно.

Таблица 2. Системы управления заплатами

Продукт Производитель Сайт
Ecora Patch Manager Ecora http://www.ecora.com
Service Pack Manager 2000 Gravity Storm Software http://www.securitybastion.com
PatchLink Update Patchlink http://www.patchlink.com
Everguard Gibraltar Software http://www.gibraltarsoft.com
SecurityProfiling SecurityProfiling http://www.securityprofiling.com
HFNetChkPro Shavlik http://www.shavlik.com
Sun Patch Manager Sun https://sunsolve.sun.com/patchpro
Bigfix Patch Manager Bigfix http://www.bigfix.com
UpdateEXPERT StBernard Software http://www.stbernard.com
Patch Management Toolkit Altiris http://www.altiris.com
AdminStudio InstallShield http://www.installshield.com
Prism Pack New Boundary Technologies http://www.newboundarytechnologies.com

Заметим, что системы Baseline Security Analyzer и HFNetChk были разработаны специально для Microsoft и предлагаются на ее сайте бесплатно. Расширенные версии этих продуктов (HFNetChkPro и EnterpriseInspector), обладающие куда большим функционалом, чем их бесплатные "собратья", можно получить на сайте фирмы Shavlik. В настоящий момент Shavlik направила свою деятельность на ОС Unix, Apache и СУБД Oracle.

Не имея сканеров или систем инвентаризации, проверять десятки и сотни узлов в поисках тех, которые требуют обновления, приходится вручную. А дальше возникает еще один вопрос, требующий внимательнейшего изучения: стоит ли устанавливать данный патч на узлы своей сети?

Иметь или не иметь?

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

Чтобы ответить на данный вопрос, необходимо установить степень критичности проблемы, которую устраняет вышедшее обновление. Самый простой способ - воспользоваться оценкой самой компании-производителя. Но таким оценкам не стоит доверять безоглядно. Например, критичность патча MS02-068, выпущенного Microsoft, сначала была определена компанией как умеренная (moderate), и только после нареканий, появившихся в списке рассылки NTBugTraq, приоритет его был поднят до критичного (critical).

Дополнительный способ проверки степени важности заплатки - применение упомянутых выше сканеров безопасности, которые ранжируют все обнаруженные проблемы по степени их важности.

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

Тестировать, тестировать и еще раз тестировать

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

Конечно, не установив заплату, нельзя с уверенностью сказать, как она повлияет на сеть. Например, 21 мая 2003 г. Microsoft выпустила патч, который был несовместим с некоторыми персональными межсетевыми экранами и заблокировал доступ в Интернет примерно 600 тыс. "послушных" пользователей, успевших установить его. 27 мая данный патч был отозван. Предварительное тестирование на стенде, имитирующем работу типовых приложений, позволило бы своевременно выявить все несовместимости и ошибки и не допустить подобного инцидента.

Всем сестрам по серьгам

После тестирования можно смело приступать к установке заплатки на все необходимые узлы. Но здесь вас ждут другие трудности.

Во-первых, заплатки далеко не всегда устанавливаются в автоматическом режиме - бывает, что требуется вручную выполнить те или иные действия, например, скопировать файлы, создать новый каталог, выполнить резервное копирование и т. п. Во-вторых, вручную установить обновления можно на 5-10 серверах, а если их десятки или сотни? А есть еще сетевое оборудование, рабочие станции и т. п.

Кстати, о рабочих станциях - их ПО тоже должно обновляться наряду с серверным. Иначе проблем не избежать, как, к примеру, не избавился от них медицинский центр в Бостоне, установивший Service Pack 3 на своих серверах баз данных Microsoft SQL Server, но позабывший о рабочих станциях с MSDE. В результате во время эпидемии червя Slammer центр потерял доступ в Интернет и не смог обрабатывать данные пациентов.

В марте 2003 г. компания Gartner опубликовала отчет, в котором утверждалось, что "ручные" подходы к управлению обновлениями неэффективны, и рекомендовалось обратить свой взор на автоматизированные системы управления заплатками. Рынок этих средств (patch management system) находится сейчас на подъеме, и такие решения выпускают многие компании (см. табл. 2). Некоторые из производителей, например, Ecora, предлагают даже комплексные системы "инвентаризация + управление обновлениями".

Как правило, подобные продукты построены на основе клиент-серверной технологии, требующей наличия агентов на каждом из контролируемых узлов. Такие агенты могут быть реализованы по-разному. Например, система BigFix требует установки на каждом клиенте своего агента в виде Java-апплета, а System Scanner - в виде сервиса или демона ОС. Устаревшая конфигурация обнаруживается либо путем расчета контрольных сумм ПО (так действует PatchLink Update), либо при помощи базы заплаток (так действуют HFNetChkPro или System Scanner). Однако, несмотря на то что многие производители (например, Ecora или Shavlik) предлагают бесплатные варианты своих решений, по статистике, не более 5% организаций в мире используют системы управления заплатками.

Время - деньги

Если вышеперечисленные этапы успешно пройдены, перед вами встает, пожалуй, самая острая проблема - время. Для самой распространенной своей платформы, Windows, Microsoft только в 2002 г. выпускала новые патчи со скоростью один в 5,5 дня. Очевидно, что отслеживать, тестировать и устанавливать обновления с такой скоростью, имея сотню-другую компьютеров в сети, - задача не из легких. Установка только одной заплатки на одном сервере (исключая процесс тестирования) может занять от 30 мин до 3 ч. Для обновления рабочей станции необходимо 25-30 мин. Как установить десятки заплат, выпущенных в течение месяца, на десятки серверов и сотни рабочих станций?

По данным фирмы PatchLink, для компании с 1000 компьютерами необходимо иметь трех выделенных сотрудников, которые будут заниматься только обновлением ПО. Многие ли компании в России имеют хотя бы одного сотрудника, который отвечал бы за управление заплатами?

Подводные камни

Необходимо сказать и пару слов о подводных камнях, с которыми могут встретиться системные администраторы в процессе установки патчей. Во-первых, необходимо следить за правильным порядком установки заплат. Часто встречающаяся ситуация: прежде чем устанавливать патч А, нужен еще и патч Б, который, в свою очередь, требует патча В, и так до бесконечности… А это значит, что процесс загрузки - тестирования - распределения - установки обновлений повторяется бесчисленное число раз со всеми вытекающими отсюда последствиями. Но и это еще не все. Установленные заплаты могут "исчезнуть" после инсталляции нового ПО или восстановления его с резервной копии, на которой патч не был установлен.

А теперь самый большой "булыжник", лежащий на пути эффективного управления обновлениями. Обновления выпускаются не для всех дыр, да и их появление нельзя назвать оперативным. Эксперт компании PiVX Solutions Тор Лархолм в списке рассылки Bugtraq так прокомментировал действия компании Microsoft: "Они быстро реагируют, когда им стучат по голове публично, но немного тормозят, когда об их проблемах им сообщают конфиденциально". За подтверждением далеко ходить не надо: специалисты CERT Пакистана, обнаружившие дыру в системе глобальной аутентификации Passport, так и не дождались от Microsoft ответа на свое сообщение, пока не провели пресс-конференцию и не сообщили всему миру о найденной уязвимости.

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

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

Порочность такой практики "умолчания" ярко иллюстрирует инцидент с компанией Symantec, которая, узнав о черве Slammer за несколько часов до начала эпидемии, никому (кроме своих клиентов!) не сообщила о возможной угрозе. Это, как известно, привело к печальным последствиям. Symantec в оправдание своих действий сделала следующее заявление: "Вы не можете получать предупреждения, пока не являетесь клиентом Symantec и не оплачиваете наши услуги". По мнению автора, это равносильно поведению человека, знающего о готовящемся теракте, но никому не сообщившего о нем.

Как же защитить себя от угроз, от которых даже производитель не разработал средств защиты? Помочь в этом может технология "виртуального патча", разработанная компанией Internet Security Systems (ISS).

Виртуальный патч

Технология Virtual Patch достаточно проста и базируется на исследованиях группы экспертов X-Force, которые занимаются поиском новых уязвимостей и атак, а также методов защиты от них круглосуточно. Полученная ими информация бесплатно публикуется в центре безопасности ISS (http://www.iss.net/security_center). Однако еще до официального опубликования результаты данных исследований становятся доступны системам обнаружения и предотвращения атак компании ISS в виде специальных модулей X-Press Updates. Кстати, по результатам исследования CNews (http://cnews.ru/security/part3/detect_rus.shtml), эти решения наиболее популярны в нашей стране.

Получив новый модуль X-Press Update, сканеры безопасности (например, Internet Scanner) проводят сканирование всех защищаемых ресурсов. При обнаружении уязвимости на каком-либо узле сети (будь то сервер, рабочая станция или сетевое устройство) они дают указание системам обнаружения и предотвращения атак (семейства RealSecure и Proventia), установленным на периметре сети или на критичных серверах, блокировать всю несанкционированную активность. Так дыра "закрывается" даже при отсутствии соответствующей заплатки. А после выпуска обновления можно спокойно приступить к его установке.

Вместо заключения

К сожалению, несмотря на стремление разработчиков создавать надежное и защищенное ПО, ошибки, дефекты и дыры в программах будут всегда. Поэтому задача эффективного управления заплатками рано или поздно встает перед любым администратором любой сети. И каждому специалисту придется выполнять описанные выше действия - тестирование, распределение и установку новых обновлений. Правда, бывший советник Буша по информационной безопасности Ричард Кларк выступил в начале года с идеей создания единого центра проверки всех патчей, и его идея была внесена в национальную стратегию защищенного киберпространства (National Strategy to Secure Cyberspace). Однако пока такого органа нет, и компаниям приходится в одиночку бороться со всеми возникшими проблемами.