Cети -> Локальные сети -> Управление патчами в корпоративной сети

Управление патчами в корпоративной сети

Алексей Лукацкий

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

ХХХХХХХХХХХХХХХХХХХХХХХХХХХХ

Врезка 1. Типы уязвимостей

Существует три класса уязвимостей, отражающие этапы жизненного цикла информационной системы:

• Уязвимости проектирования. Наиболее серьезный класс дыр, обнаруживаемых и устраняемых с большим трудом. Пример: уязвимость стека протоколов TCP/IP.
• Уязвимости реализации. Возникают на этапе реализации в программном или аппаратном обеспечении корректного с точки зрения безопасности проекта или алгоритма. Обнаруживаются и устраняются подобного рода уязвимости относительно легко.
• Уязвимости конфигурации. Возникают в процессе конфигурации. Этот вид, наряду с уязвимостями реализации, является самой распространенной категорией дыр.

ХХХХХХХХХХХХХХХХХХХХХХХХХХХХ

А есть ли проблема?

Согласно исследованиям ФБР и Университета Карнеги-Меллона 98% инцидентов возникает из-за проблемы, о которой IT-отдел уже знал, но не устранил. Аналитики Gartner считают, что эта цифра чуть ниже - около 90%. Эксперты координационного центра по безопасности CERT утверждают, что 95% инцидентов, о которых им сообщают, используют известные дыры. Можно заметить общую тенденцию - более 90% всех проблем с компьютерной безопасностью происходит по причине невнимательности со стороны администраторов, одной из задач которых и является своевременная защита постоянно появляющихся дыр в корпоративной сети.

Пример с SQL Slammer яркое тому подтверждение. Компания Microsoft выпустила для этого червя заплату еще в июле 2002 года, за полгода до начала эпидемии, но это не помешало ему натворить немалых бед (см. врезку "Червь Slammer. Маленький, да удаленький").

ХХХХХХХХХХХХХХХХХХХХХХХХХХХХ

Врезка 2. Червь Slammer. Маленький, да удаленький.

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

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

ХХХХХХХХХХХХХХХХХХХХХХХХХХХХ

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

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

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

ХХХХХХХХХХХХХХХХХХХХХХХХХХХХ

Врезка 3. Как узнать о патче?

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

• Oracle
• Microsoft
• Sun

ХХХХХХХХХХХХХХХХХХХХХХХХХХХХ

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

ХХХХХХХХХХХХХХХХХХХХХХХХХХХХ

Врезка 4. Системы инвентаризации сети

• AssetMatrix одноименной компании
• LANAuditor компании iInventory
• TSCensus компании Tally Systems
• Tivoli Inventory компании IBM
• Ecora Auditor Suite компании Ecora

ХХХХХХХХХХХХХХХХХХХХХХХХХХХХ

Другой подход в поиске непропатченных узлов - использование сканеров безопасности. Отсутствие заплатки - по сути своей уязвимость, позволяющая злоумышленникам реализовывать свои атаки. Поэтому многие сканеры безопасности обладают такой возможностью, как контроль патчей и других обновлений. В России в настоящий момент широко используются различные сканеры компании Internet Security Systems, а также отечественная разработка - XSpider от Positive Technologies. Такие сканеры содержат в своем составе базу заплаток для различных операционных систем и приложений и сравнивают текущее состояние сканируемого узла со своей базой.

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

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

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

А стоит ли ставить?

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

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

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

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

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

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

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

Как распределить?

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

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

В марте 2003 года Gartner опубликовала отчет, в котором утверждалось, что ручные подходы в управлении обновлениями неэффективны и рекомендовала обратить свой взор на автоматизированные системы управления заплатками.

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

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

И, несмотря на то, что многие производители предлагают бесплатные варианты своих решений (например, Ecora или Shavlik) по статистике не более 5% организаций в мире используют системы управления заплатками.

ХХХХХХХХХХХХХХХХХХХХХХХХХХХХ

Врезка 5. Системы управления заплатами

• Ecora Patch Manager компании Ecora
• Service Pack Manager 2000 компании Gravity Storm Software
• PatchLink Update компании Patchlink
• Everguard компании Gibraltar Software
• SecurityProfiling
• HFNetChkPro
• Sun Patch Manager
• Bigfix Patch Manager компании Bigfix
• UpdateEXPERT компании StBernard Software
• Patch Management Toolkit от Altiris
• AdminStudio компании InstallShield
• Prism Pack компании New Boundary Technologies

ХХХХХХХХХХХХХХХХХХХХХХХХХХХХ

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

Даже если вышеперечисленные этапы вами успешно пройдены, встает иная проблема - время. Если обратиться к самой распространенной платформе - Windows, то выяснится, что в 2002 году компания Microsoft выпускала новые патчи со скоростью один патч в 5.5 дней. Многие специалисты просто не успевают отслеживать, тестировать и устанавливать обновления с такой скоростью. А с увеличением числа обновляемых узлов ситуация усугубляется.

Проблемы нарастают как снежный ком. Установка только одной заплатки на одном сервере (исключая процесс тестирования) может занять от 30 минут до 3-х часов. Для обновления рабочей станции необходимо 25-30 минут. И вот тут в очередной раз проявляется человеческий фактор. Как установить десятки заплат, выпущенных в течение месяца на десятки серверов и сотни рабочих станций? По данным компании PatchLink для компании с 1000 компьютерами необходимо иметь трех выделенных сотрудников, которые будут заниматься только этой задачей. Многие ли компании в России имеют хотя бы одного сотрудника, который бы отвечал за управление заплатами?

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

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

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

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

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

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

Виртуальный патч? Это реально!

Технология Virtual Patch достаточно проста и базируется на исследованиях группы экспертов X-Force, которые в круглосуточном режиме занимаются поиском новых уязвимостей и атак, а также методов защиты от них. Эта информация бесплатно публикуется в Центре Безопасности ISS. Кроме того, еще до официального опубликования результаты всех исследований в виде специальных модулей X-Press Updates распределяются по системам обнаружения и предотвращения атак, разработанных компанией ISS. Кстати, по результатам исследования CNews эти решения являются самыми распространенными в России.

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

Заключение

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