Windows и Linux: что безопаснее?
Много копий было сломано в спорах о том, действительно ли Linux — более безопасная операционная система, чем Windows. Мы сравнили Windows и Linux по значениям следующих параметров в 40 последних программных коррекциях/уязвимостях для Microsoft Windows Server 2003 и Red Hat Enterprise Linux AS v.3:
1. Серьезность уязвимостей в системе безопасности, которая оценивается по следующим показателям:
- возможный ущерб (насколько велик вред от использования ОС с незакрытой уязвимостью);
- возможность использования (насколько легко использовать данную уязвимость);
- возможная доступность (какого рода доступ требуется для использования данной уязвимости?).
2. Количество уязвимостей, серьезность которых определяется как rритическая.
Результаты сравнения не оказались неожиданными. Даже по субъективным и заниженным стандартам, применяемым Microsoft, по меньшей мере 38% последних программных коррекций предназначены для ликвидации брешей, которые Microsoft относит к критическим. Только 10% программных коррекций и предупреждений в Red Hat относятся к брешам, имеющим критический уровень серьезности. Приведенные результаты получены при условиях, благоприятных для Microsoft и обоснованно жестких для Red Hat, так как они основаны на критериях Microsoft, а не на используемых нами более строгих показателях безопасности. Если применить наши собственные критерии, то количество критических брешей в Windows Server 2003 возрастет до 50%.
Результаты запроса к базе данных Computer Emergency Readiness Team (CERT) подтвердили наши выводы, сделав разницу еще более значительной. Расположив полученные данные по убыванию серьезности (от более критических к менее критическим), мы обнаружили, что уровень серьезности 39 из первых 40 записей в базе данных CERT для Windows превышает пороговое значение, установленное CERT для серьезных предупреждений. Лишь три из первых 40 записей оказались выше указанного порога в результатах запроса к этой базе данных для ключевого слова «Red Hat». Запрос к базе данных CERT для «Linux» показал, что только шесть из первых 40 записей находятся выше этого порогового значения.
Следует также учесть тот факт, что в списки как для Red Hat, так и для Linux включаются бреши в программном обеспечении, которое функционирует в Windows, а это означает, что такие бреши относятся одновременно и к Linux, и к Windows. Ни одно из предупреждений, связанных с Windows, не относится к программному обеспечению, функционирующему в Linux.
Почему же тогда так много, на первый взгляд, убедительных уверений в том, что операционная система Linux в действительности менее безопасна, чем Windows? Обоснование вывода о меньшей безопасности Linux содержит вопиющие логические несоответствия. Нужно всего лишь чуть внимательнее рассмотреть этот вопрос, чтобы развенчать мифы и найти логические ошибки, лежащие в основе следующих часто повторяемых утверждений. В статье будеь дан также краткий обзор существенных различий в концепциях Windows и Linux, что позволяет понять, почему операционная система Windows более уязвима к атакам как на серверах, так и на настольных компьютерах, и почему Linux является более безопасной системой.
развенчание мифов
Миф 1. Безопасность — вопрос количества: чем меньше инсталляций, тем безопаснее.Пожалуй, чаще всего повторяемый миф при сравнении безопасности Windows и Linux — утверждение, что с ОС Windows случается больше инцидентов, связанных с вирусами, сетевыми червями, троянскими программами и другими проблемами, только из-за того, что злоумышленники предпочитают вмешиваться в работу программного обеспечения, которое имеет наибольшую инсталляционную базу. Это рассуждение приводят в защиту ОС Windows и Windows-приложений. Windows преобладает на настольных компьютерах; именно поэтому на Windows и Windows-приложения направлено большинство атак, и именно поэтому не наблюдаются вирусы, сетевые черви и троянские кони для Linux. Нельзя отрицать, что до некоторой степени это верно, однако отнюдь не бесспорен вывод, который отсюда делается, а именно: Linux и Linux- приложения не являются более безопасными, чем Windows и Windows-приложения, просто Linux — слишком незначительная цель для того, чтобы тратить усилия на организацию атаки.
Это рассуждение легко опровергнуть, если учесть, что самым популярным программным обеспечением для веб-серверов является Apache. Как следует из выполненного компанией Netcraft обзора веб-сайтов за сентябрь 2004 г., 68% сайтов используют веб-сервер Apache /* предполагается, что большинство этих серверов работает под управлением UNIX-подобных ОС, а самая распространенная из них – Linux – прим. ред */ и только 21% сайтов используют Microsoft IIS. Если проблемы с безопасностью возникают из-за того, что злоумышленники нацеливаются на самую обширную инсталляционную базу, то должно наблюдаться больше червей, вирусов и прочих вредоносных программ, нацеленных на Apache и те операционные системы, под управлением которых он функционирует, чем на Windows и IIS. Более того, должно регистрироваться больше атак против Apache, чем против IIS, так как из приведенного выше рассуждения следует, что проблема заключается в количествах, а не в уязвимостях.
Однако в реальности наблюдается обратная картина. В течение долгого времени IIS был главной целью для сетевых червей и других атак, и эти атаки были весьма успешными. Сетевой червь Code Red, который использовал переполнение буфера в сервисе IIS для получения контроля над веб-серверами, заразил около 300 тысяч серверов, и его распространение прекратилось лишь потому, что это было предусмотрено в программном коде данного червя. Воздействие еще одного сетевого червя IISWorm оказалось ограниченным только благодаря тому, что эта программа была плохо написана, а вовсе не из- за успешной защиты IIS.
Да, известны сетевые черви для Apache, например, Slapper (в действительности Slapper использует известную уязвимость в протоколе OpenSSL, а не в Apache). Но сетевые черви для Apache редко становятся сенсацией, поскольку их воздействие очень ограничено и они легко искореняются. На атакуемых сайтах уже были приняты меры, исключающие возможность использования ошибки в OpenSSL. Кроме того, благодаря модульной структуре Linux и *NIX было очень просто очистить и восстановить зараженные сайты. Для этого потребовалось всего несколько команд и не было необходимости в перезагрузке.
Возможно, именно поэтому в рейтинге Netcraft среди 50 web-сайтов, лидирующих по длительности непрерывной работы (промежуток времени между перезагрузками), оказалось 47, использующих Apache. Ни на одном из этих 50 web-сайтов не использовались ни Windows, ни Microsoft IIS. Поэтому, если верно предположение, что злоумышленники атакуют наиболее распространенные программные платформы, то возникает вопрос: почему хакеры так успешно взламывают программное обеспечение и операционную систему, самые популярные среди настольных компьютеров, заражают 300 тысяч серверов IIS, но неспособны нанести подобный ущерб наиболее популярному веб-серверу и типичным для него операционным системам?
Читатели, посещавшие Netcraft, не могут не заметить, что все 50 серверов из списка лучших по длительности непрерывной работы используют какую- либо разновидность BSD, в основном BSD/OS. Только пара из них функционирует под управлением Windows и ни один — под управлением Linux. Самое продолжительное время непрерывной работы среди 50 лидеров составляет 1772 дней подряд или почти 5 лет.
В результате складывается впечатление, что BSD по своей надежности превосходит все остальные операционные системы, однако информация Netcraft, хотя и непреднамеренно, вводит в заблуждение. Netcraft определяет продолжительность непрерывной работы операционных систем по данным, которые регистрируются самими операционными системами. Linux, Solaris, HP-UX и некоторые версии FreeBSD регистрируют не более 497 дней непрерывной работы, после чего счетчики обнуляются, и отсчет начинается заново. Поэтому и кажется, что все веб-сайты, размещенные на компьютерах под управлением Linux, Solaris, HP-UX и, в некоторых случаях, FreeBSD, перезагружаются каждые 497 дней, даже если они функционируют годами. Это объясняет, почему Linux, Solaris и HP-UX не могут продемонстрировать такой же впечатляющий результат по количеству последовательных дней непрерывной работы, как BSD, даже если на самом деле эти операционные системы годами функционируют без перезагрузки. Но это не объясняет, почему среди 50 лидеров мало серверов под управлением ОС Windows. Windows не обнуляет счетчик времени непрерывной работы. Очевидно, сайты под управлением ОС Windows, которые функционировали бы без перезагрузки достаточно долго, чтобы попасть в список 50 лучших – это, скорее, исключение.
Из всего вышесказанного следует вывод, что при оценке количества успешных атак на программное обеспечение решающий фактор — это качество, а не количество.
Миф 2. Открытый код опасен по определению.Впечатляющие данные о продолжительности непрерывной работы, полученные для Apache, позволяют усомниться еще в одном популярном мифе: открытый исходный код (в котором функциональная структура приложений является общедоступной) более опасен, чем патентованный исходный код (в котором функциональная структура является засекреченной), поскольку хакеры могут воспользоваться этим кодом для обнаружения и использования брешей.
Однако факты говорят о другом. Количество предназначенных для ОС Windows эффективных вирусов, программ-шпионов, сетевых червей, троянских и других вредоносных программ огромно, а количество компьютеров, постоянно заражаемых различными комбинациями вышеперечисленного, так велико, что вряд ли поддается исчислению. Вредоносное программное обеспечение "свирепствует" настолько, что для компрометации свежеустановленной, "непропатченной" версии Windows XP после подключения компьютера к Интернету требуется в среднем 16 минут — меньше, чем время, необходимое данной ОС для загрузки и инсталляции программных коррекций, которые позволят защитить этот компьютер.
Еще один пример. Веб-сервер Apache имеет открытый код. Microsoft IIS — патентованный. В этом случае факты опровергают и миф о наибольшей популярности, и миф об опасности открытого кода. Apache — наиболее популярный веб-сервер. Если бы оба эти мифа были правдой, следовало бы ожидать, что Apache и операционные системы, под управлением которых он функционирует, будут чаще подвергаться атакам, чем Microsoft Windows и IIS. На деле же все происходит с точностью до наоборот. Apache занимает почти монопольное положение в списке серверов с наибольшей
продолжительностью непрерывной работы. Очевидно, тот факт, что злоумышленники имеют доступ к открытому коду Apache, не дает им никакого преимущества в организации более успешных атак против Apache, чем против IIS.
Миф 3. Выводы на основании единственной характеристики.Слабость других популярных мифов о большей безопасности Windows по сравнению с Linux в том, что они основаны на единственном показателе — каком-нибудь одном аспекте измерения безопасности. Это верно для любого источника информации, будь то данные компетентного исследования или малообоснованная информация на уровне слухов.
Широко известно утверждение: "Для Linux зарегистрировано больше предупреждений об уязвимостях, чем для Windows, поэтому можно говорить о меньшей безопасности Linux по сравнению с Windows". Не менее распространено и такое: "Время между обнаружением бреши и созданием соответствующей программной коррекции в случае Linux больше, чем в случае Windows, поэтому можно говорить о меньшей безопасности Linux по сравнению с Windows". Второе утверждение совершенно непостижимо. Невозможно объяснить, почему считается, что по такому показателю, как среднее время от момента обнаружения бреши до выпуска соответствующей программной коррекции, Microsoft превосходит какую-либо из конкурирующих операционных систем, не говоря уже о Linux. Компании Microsoft потребовалось семь месяцев (!), чтобы устранить одну из самых серьезных уязвимостей в системе защиты (Microsoft Security Bulletin MS04-007 ASN.1 Vulnerability, компания eEye Digital Security сообщила об этой задержке в информационном бюллетене AD20040210). А ведь еще имеются бреши, о которых Microsoft открыто заявляет, что они никогда не будут ликвидированы. В бюллетене Microsoft Security Bulletin MS03-010 об уязвимости Denial Of Service (отказ в обслуживании) в Windows NT говорится, что эта уязвимость никогда не будет устранена. Позднее компания Microsoft заявила, что не будут устраняться уязвимости в Internet Explorer для всех версий операционных систем, выпущенных ранее Windows XP. В статистическом смысле случай с семью месяцами между обнаружением и устранением ошибки не окажет значительного влияния на среднее время реагирования при условии, что найдется достаточно много примеров чрезвычайно быстрого реагирования, которые скомпенсируют подобные аномалии, если это действительно аномалии. Но стоит включить в выборку только один случай "никогда" — и о статистическом среднем можно забыть навсегда.
Оставив в стороне эту неразрешимую загадку, рассмотрим, есть ли основания полагать, что Linux менее безопасна, чем Windows, потому что среднее время между обнаружением уязвимости и выпуском соответствующей программной коррекции в случае Linux больше, чем в случае Windows. Зададим себе вопрос: "Если прямо сейчас у меня случится сердечный приступ, в какое отделение скорой помощи я предпочту попасть? Туда, где среднее время между регистрацией пациента и оказанием ему помощи самое короткое? Или я предпочту отделение, где это среднее время дольше, но зато пациенты с самыми серьезными диагнозами получают помощь в первую очередь?"
Очевидно, что следует выбрать второе отделение, но вовсе не потому, что из приведенной выше информации ясно, что оно лучше первого. Этот вариант предпочтительнее, потому что он выбран по двум показателям, один из которых особенно важен для вас именно в данный момент. Можно с уверенностью утверждать: мало кто захочет попасть в больницу, о которой известно, что в ней есть шанс умереть от сердечного приступа, ожидая, пока врач закончит вправлять кому-то вывихнутый мизинец — каким бы впечатляющим ни было "среднее время реагирования на запрос о медицинской помощи". Трудность в том, что в приведенном примере недостаточно информации для принятия оптимального решения. Ничего не известно о том, как больница с наименьшим "временем реагирования" определяет, кому из больных следует уделить внимание в первую очередь. Кроме того, неплохо бы иметь информацию о показателе смертности среди больных, нуждающихся в неотложной помощи, о квалификации врачей и т. д.
Очевидно, что для правильного выбора есть только один способ — собрать об окрестных отделениях скорой помощи подробную информацию, т.е. узнать как можно больше важных показателей и найти разумный компромисс между этими показателями. Было бы непростительной безответственностью рекомендовать отделение скорой помощи для случая сердечного приступа, основываясь только на одном показателе, например, на времени реагирования, среднем для всех неотложных случаев, особенно если без труда можно получить другую важную информацию, которая позволит сделать лучший выбор. В той же степени неразумно и безответственно давать рекомендации или принимать серьезное экономическое решение на основании единственного показателя, такого как среднее время между обнаружением бреши и ее устранением для той или иной операционной системы, или такого показателя, как количество предупреждений об уязвимостях для того или иного продукта.
Любой отдельно взятый показатель может ввести в заблуждение, поскольку неясна его значимость. Рассмотрим утверждение, что известно больше предупреждений для программного обеспечения Linux, чем для Windows. Эта статистика бессмысленна, потому что не отвечает на самые важные вопросы. Сколько брешей из зафиксированных всеми предупреждениями об уязвимостях создают реальные угрозы? Насколько серьезны эти угрозы? Насколько вероятно, что их использование причинит серьезный ущерб компьютерам? Ответы на эти вопросы имеют большое значение. Что лучше, операционная система со 100 брешами, из-за которых возможен незначительный ущерб (а то и вовсе никакого) и которыми не сможет воспользоваться никто, кроме локальных пользователей с действующими учетными записями и физическим доступом к компьютеру? Или стоит предпочесть операционную систему с единственной критической брешью, из-за которой любой хакер из Интернета может уничтожить всю информацию на сервере? Ясно, что само по себе количество предупреждений не является значимым показателем, указывающим на большую безопасность одной операционной системы по сравнению с другой.
архитектура Windows и архитектура Linux
У нас пока остался без ответа один важный вопрос. Действительно ли атаки на Windows столь успешны исключительно из-за их многочисленности, или же этот факт объясняется наличием проектных недоработок и неудачных проектных решений Windows?
Значительная часть (если не большинство) вирусов, троянских коней, сетевых червей и других вредоносных программ, заражающих компьютеры с Windows, используют для этого уязвимости в Microsoft Outlook и Internet Explorer. Поэтому можно поставить вопрос по-другому, включив в рассмотрение тот же тип программного обеспечения для Linux (наиболее часто используемые браузеры, программы электронной почты, текстовые процессоры и т. д.): имеет ли Linux столько же уязвимостей в системе безопасности, сколько их имеет Windows?
архитектура Windows
Вирусы, троянские кони и другие вредоносные программы поражают настольные компьютеры с Windows по целому ряду причин, свойственных Windows и чуждых Linux:
1. Windows только недавно эволюционировала от однопользовательской модели к многопользовательской. Критики Linux любят повторять, что Linux — это "устаревшая" технология. Ирония же заключается в следующем: одна из самых больших проблем Windows в том, что именно этой операционной системе никак не удается избавиться от своей "устаревшей" однопользовательской архитектуры.
В течение долгого времени происхождение от однопользовательской системы мешало Windows. Система Windows изначально была разработана так, чтобы обеспечить и пользователям, и приложениям свободный доступ ко всей системе, а это значит, что кто угодно мог скомпрометировать критичную системную программу или файл. Кроме того, это означает, что вирусы, троянские и другие вредоносные программы могли скомпрометировать любую системную программу или файл, потому что Windows не изолировала пользователей и приложения от критичных областей операционной системы. Windows XP стала первой версией Windows, в которой проявились существенные результаты усилий по изолированию пользователей от системы, так что в Windows XP каждый пользователь имеет свои собственные личные файлы и ограниченные системные полномочия. Но из-за этого многие Windows- приложения, разработанные для предыдущих версий, перестали функционировать, поскольку раньше они могли получать доступ и модифицировать программы и файлы, доступ к которым теперь разрешен только администратору. Именно поэтому в Windows XP предусмотрен режим совместимости, то есть режим, который позволяет программам функционировать так, будто они работают в прежней незащищенной однопользовательской среде. Кроме того, именно по этой причине каждая новая версия Windows несет в себе угрозу отказа приложений, работавших в предыдущих версиях. Поскольку Microsoft вынуждена модифицировать Windows, чтобы она "вела себя" как многопользовательская система, новые ограничения выводят из строя приложения, которые функционировали при отсутствии этих ограничений.
Windows XP — это прогресс, но и Windows XP нельзя назвать настоящей многопользовательской системой. Например, Windows XP поддерживает функцию, которую Microsoft называет "Fast User Switching" (быстрое переключение пользователей), она же позволяет двум и более пользователям входить в систему Windows XP на одном компьютере в одно и то же время. Однако есть загвоздка. Это возможно тогда и только тогда, когда данный компьютер не принадлежит какому-либо домену сети Windows. Причина в том, что сеть Microsoft разработана в предположении, что обычно пользователи входят в сеть только со своего собственного компьютера. Microsoft либо не может, либо не желает внести необходимые изменения в операционную систему и "конструкцию" сети, чтобы адаптировать этот сценарий к возможностям Windows XP.
Windows Server 2003 — это следующее приближение к настоящей многопользовательской системе, но даже в Windows Server 2003 не удалось ликвидировать все бреши в системе защиты, унаследованные от однопользовательской системы. Именно поэтому в Windows Server 2003 пришлось отключить использование по умолчанию многих функций веб-браузера (например, ActiveX, написание сценариев и др.). Если бы Microsoft перестроила эти функции для работы в безопасном и изолированном режиме в настоящей многопользовательской среде, они не создавали бы серьезных угроз, перед которыми по-прежнему беззащитна Windows.
2. Windows по своей архитектуре является монолитной, а не модульной системой. Монолитная система — это система, в которой большинство функций интегрировано в единый модуль. Противоположностью такой системе является система, в которой функции распределены по нескольким уровням, причем каждый уровень имеет ограниченный доступ к другим уровням.
Хотя часть недостатков Windows — "наследство" ее исходной однопользовательской архитектуры, другие ее недостатки — прямое следствие обдуманных проектных решений, таких как монолитная архитектура (интегрирование большинства функций в ядро операционной системы). Компания Microsoft фактически вытеснила веб-навигатор Netscape, интегрировав Internet Explorer в свою операционную систему так тесно, что не использовать IE стало практически невозможно. /* да нет же, не использовать IE, конечно, возможно, а вот удалить из системы – очень и очень проблематично – прим. ред. */ Нравится это пользователю или нет, но Internet Explorer вызывается при использовании справочной системы Windows, Outlook и многих других приложений как Microsoft, так и независимых производителей. Конечно, коммерческие интересы Microsoft требуют, чтобы использование каких-либо иных продуктов, кроме Internet Explorer, было крайне затруднительным. Microsoft успешно превращает конкурирующие продукты в ненужные, интегрируя в свою операционную систему все больше и больше сервисов, предоставляемых такими продуктами. Но в результате этого подхода получается монстр из сложным образом взаимодействующих сервисов (то есть, по определению, монолитная система).
Взаимозависимости такого рода имеют два неприятных каскадных побочных эффекта. Во-первых, в монолитной системе каждая брешь в какой-либо одной части системы проявляется во всех сервисах и приложениях, зависящих от этой части системы. Интегрировав Internet Explorer в операционную систему, Microsoft создала систему, в которой любая брешь в Internet Explorer подвергает настольный компьютер с Windows угрозам, реализация которых может нарушить не только работу браузера, но и весьма далеких от него объектов. Следовательно, одна-единственная брешь в Internet Explorer проявляется в бесчисленном множестве других приложений, многие из которых используют Internet Explorer неявным для пользователя образом, что дает этому пользователю ложное ощущение безопасности.
Такая архитектурная модель оказывает намного более глубокое воздействие, чем обычно представляют. Так, в монолитной системе уязвимости в защите оказываются более критичными, чем следовало ожидать.
Проиллюстрировать это поможет простая аналогия. Представим себе идеально устроенную операционную систему, которая состоит из трех сфер: одна — в центре; вторая, большего размера, охватывает первую; а третья сфера охватывает две внутренние. Конечный пользователь "видит" только внешнюю сферу. Это уровень, где пользователь запускает приложения, например, текстовые процессоры. Текстовые процессоры используют необходимые функции, предоставляемые второй сферой, например, средства визуализации графических изображений или форматирования текста. Эта вторая сфера (ее специалисты обычно называют "пользовательскими процессами") не имеет прямого доступа к критичным частям системы. Чтобы выполнить свою работу, она должна запросить разрешение от самой внутренней сферы. Внутренняя сфера выполняет самые важные функции, поэтому имеет непосредственный доступ ко всем критичным частям системы. Она управляет дисками, памятью и всем остальным. Эта сфера называется "ядро" и является сердцем операционной системы.
В случае вышеописанной архитектуры брешь в программах графического отображения не может нанести глобального ущерба компьютеру, потому что функции визуализации не имеют прямого доступа к наиболее критичным частям системы. Даже если пользователь загрузит в текстовый процессор изображение с внедренным вирусом, этот вирус не сможет повредить ничего, кроме собственных файлов пользователя, поскольку функция графического отображения находится вне центральной сферы и не имеет доступа ни к одной из критичных частей системы.
Проблема Windows заключается в том, что в ней не соблюдаются разумные конструкторские принципы разделения функций по соответствующим уровням, описанным выше. Windows вкладывает слишком много функций в ядро, центральную сферу, то есть туда, где можно причинить самый большой ущерб. Например, если интегрировать функции графического отображения в центральную сферу (ядро), эти функции получат возможность повредить всю систему. Таким образом, как только обнаружится брешь в алгоритме графического отображения, чрезмерно интегрированная архитектура Windows облегчит использование этой бреши для получения полного контроля над системой или для разрушения всей системы.
Наконец, монолитная система нестабильна по своей природе. Когда в системе так много взаимосвязей, изменение одной из частей этой системы порождает множество угроз. Единственное изменение в системе может оказать (и обычно оказывает) каскадное воздействие на все сервисы и приложения, которые зависят от этой части системы. Именно поэтому пользователи Windows трепещут при мысли об установке программных коррекций и обновлений. Обновления, исправляющие одну часть Windows, часто нарушают работу других сервисов и приложений. В качестве иллюстрации можно привести следующий факт: для пакета обновлений Windows XP service pack 2 уже составлен постоянно растущий список случаев, когда его установка привела к выходу из строя сторонних приложений. Это естественное явление в монолитной системе — любое изменение в одной части механизма влияет на весь механизм и на все приложения, которые зависят от этого механизма.
3. В Windows слишком широко используется RPC-механизм. Аббревиатура RPC означает "удаленный вызов процедуры" (Remote Procedure Call). RPC — это то, что происходит, когда одна программа отправляет через сеть указание другой программе выполнить какое-либо действие. Например, одна программа может использовать RPC, чтобы дать другой программе указание рассчитать среднюю стоимость чая в Китае и вернуть результат. Удаленным вызовом процедуры этот механизм называется потому, что не имеет значения, функционирует ли "другая программа" на том же компьютере, на соседнем или где-то в Интернете.
RPC-механизмы — это потенциальная угроза безопасности, поскольку их предназначение — позволить компьютерам, находящимся где-то в сети, давать данному компьютеру указания выполнить те или иные действия. Как только обнаруживается брешь в программе, разрешающей использование RPC-механизма, у любого, кто располагает подключенным к сети компьютером, появляется возможность использовать эту брешь, чтобы заставить уязвимый компьютер выполнить какие-либо действия. К сожалению, пользователи Windows не могут заблокировать RPC-механизм, так как Windows использует его, даже если компьютер не подключен к сети. Многие сервисы Windows устроены именно так. В некоторых случаях можно блокировать RPC-порт на межсетевом экране, но Windows так широко использует RPC-механизмы в основных функциях, что подобная блокировка не всегда возможна. Удивительно, но некоторые из наиболее серьезных уязвимостей в Windows Server 2003 — следствие брешей в самих RPC-функциях Windows, а не в приложениях, которые их используют. Самый распространенный способ использовать уязвимость, связанную с RPC-механизмом — атаковать сервис, использующий RPC, а не сам RPC-механизм.
Важно отметить, что RPC-механизмы не всегда необходимы, отчего становится еще непонятнее, почему Microsoft так широко их использует. Предположим, требуется создать веб-сайт, используя два сервера. Один сервер будет работать в качестве сервера базы данных, второй — в качестве веб-сервера. В этом случае серверу базы данных необходимо использовать RPC, потому что веб-сервер находится на отдельном компьютере и должен иметь возможность доступа к серверу базы данных через сетевое подключение. (Даже в этом случае следует сконфигурировать сервер базы данных так, чтобы он "слушал" только данный веб-сервер, но не другие компьютеры). Если же и сервер базы данных, и веб-сервер функционируют на одном компьютере, использование RPC-механизмов на сервере базы данных не только не обязательно, но и нежелательно. Веб-сервер должен иметь прямой доступ к серверу базы данных, потому что они оба функционируют на одном компьютере. Ни технических, ни логических причин подключать к сети сервер базы данных нет, поскольку такое подключение создает лишнюю угрозу безопасности.
Вопрос о серверах баз данных поднят из-за того, что сетевой червь Slammer, один из самых опасных червей, когда-либо существовавших в Интернете, использовал на редкость неуместное применение RPC-подобных сетевых соединений, реализованное Microsoft. За короткое время Slammer заразил так много систем, что Интернет практически перестал функционировать.
Сетевой червь Slammer вызвал хаос, использовав две бреши в Microsoft SQL Server, который является сервером клиент-серверной базы данных. Одна брешь — это самая бесполезная функция Microsoft SQL Server, позволяющая одновременно запустить несколько копий сервера базы данных на одном компьютере. Почему эта функция бесполезна? Если вы незнакомы с работой серверов баз данных, представьте это себе следующим образом. В обычных условиях бессмысленно запускать несколько копий сервера базы данных на одном компьютере, потому что одна копия — это все, что нужно, даже если ее использует множество разных приложений. Потребность в одновременном запуске нескольких серверов баз данных на одном компьютере также вероятна, как потребность в одновременном запуске двух копий Windows XP на одном компьютере. Несколько копий сервера базы данных запускаются не по ошибке исключительно редко, да и то лишь в высокопроизводительных приложениях или для тестирования и разработки.
Кажется, мы поняли, почему Microsoft решила установить по умолчанию именно этот режим функционирования SQL Server. Многие сторонние приложения используют процессор SQL Server по умолчанию. Если бы на компьютере могла функционировать только одна копия SQL Server, то Microsoft пришлось бы разработать удобные средства, позволяющие программе инсталляции обнаружить установленный и функционирующий SQL Server, а затем обеспечить удобный способ инсталляции, интеграции и администрирования особых требований сторонних приложений в своей собственной базе данных и в таблицах, функционирующих на данном сервере. Это очень элегантное решение, минимизирующее используемые ресурсы, поскольку всегда требуется только одна копия SQL Server. Но такой подход потребовал бы большой дополнительной работы со стороны Microsoft или со стороны независимых разработчиков. Намного проще реализовать решение, позволяющее сторонним приложениям не заботиться о том, инсталлирован ли SQL Server. По схеме, реализованной Microsoft, любое стороннее приложение может просто инсталлировать свою собственную копию SQL Server, не беспокоясь о том, установлен ли SQL Server на данном компьютере, какая версия SQL Server инсталлирована, как сконфигурирован существующий SQL Server. Стремясь привлечь независимых разработчиков к использованию SQL Server, Microsoft выбрала принцип наименьшего действия и разработала систему, в которой любое приложение может инсталлировать свою собственную копию SQL Server, которая не взаимодействует с другими копиями SQL Server, функционирующими на том же компьютере. Из-за этого возникла необходимость в запуске несколько копий SQL Server с задействованным RPC-механизмом, который следовало бы использовать как можно реже. Этот наименее затратный подход имел чрезвычайно пагубные последствия. Если бы Microsoft разработала SQL Server так, чтобы он функционировал как единственная копия, не подключенная по умолчанию к сети, то сетевой червь Slammer не нашел бы достаточно компьютеров с работающим SQL Server, чтобы причинить сколько-нибудь значительный ущерб.
Простой способ обеспечить одновременную работу нескольких не мешающих друг другу копий SQL Server — создать RPC-механизм, который сортирует запросы на получение данных таким образом, что, например, приложение-факс запрашивает одну копию SQL Server, а приложение-ежедневник — другую. Ситуация усложняется тем, что и средства разработки Microsoft поддерживают тот же принцип монолитности, который используется в продуктах Microsoft. Поэтому самые разные приложения — программы планирования времени, программное обеспечение для факсимильной связи, системы управления проектами — почти 200 приложений, многие из которых предназначены для настольных систем, используют неоправданно уязвимый процессор SQL Server. В результате сотни тысяч, если не миллионы, людей используют настольные приложения, зависящие от процессора SQL Server с его многочисленными разрешенными сетевыми сервисами, немалая часть которых уязвима к атакам из Интернета. Вряд ли можно придумать лучший способ устроить катастрофу. В результате Slammer смог атаковать огромное количество компьютеров, потому что на всех процессорах SQL Server использование этих функциональных возможностей разрешено по умолчанию. Хотя SQL Server еще не интегрирован в Windows, его повсеместное использование в различных приложениях — от программного обеспечения для факсимильной связи до программ планирования времени — фактически превращает его в часть более крупной монолитной системы, что открывает возможность такой организации атаки, которая характерна для монолитной системы. К сожалению, весьма вероятно, что SQL Server будет тесно интегрирован в File System WinFS, новую перспективную файловую систему Windows, первоначально предназначавшуюся для Longhorn, операционной системы нового поколения. Горячим сторонникам идеи интеграции SQL Server в операционную систему следует помнить об истории с сетевым червем Slammer.
4. Windows фокусируется на знакомом графическом интерфейсе для настольных компьютеров. Компания Microsoft считает знакомый интерфейс Windows главным аргументом в пользу перехода на Windows Server 2003. Цитата с web-сайта компании Microsoft: "Знакомый интерфейс Windows облегчает использование Windows Server 2003. Новые удобные мастера упрощают установку специальных ролей и выполнение обычных задач управления сервером..." Пропагандируя такое использование, Microsoft предлагает администраторам работать с ОС Windows Server 2003 на самом сервере, зарегистрировавшись с полномочиями администратора. В результате администратор Windows становится наиболее уязвимым к брешам в системе защиты, поскольку использование уязвимых программ, таких как Internet Explorer, создает угрозы безопасности сервера.
архитектура Linux
То обстоятельство, что вирусы, троянские и другие вредоносные программы редко могут (если вообще могут) заразить Linux-системы, частично можно объяснить следующими причинами.
1. Linux имеет долгую историю использования тщательно проработанной многопользовательской архитектуры. Linux никогда не была
однопользовательской операционной системой. Поэтому в ней с самого начала заложен принцип изолирования пользователей от приложений, файлов и каталогов, воздействующих на операционную систему в целом. Каждому пользователю предоставляется пользовательский каталог, в котором хранятся все его файлы данных и файлы конфигурации, принадлежащие этому пользователю. Когда пользователь запускает какое-либо приложение (например, текстовый процессор), оно запускается с ограниченными полномочиями данного пользователя. Запущенное пользователем приложение имеет право на запись только в собственный каталог этого пользователя. Оно не может ничего записать в системный файл или даже в каталог другого пользователя, если только администратор явным образом не предоставит данному пользователю такое право.
Еще важнее, что Linux предоставляет почти все функциональные возможности (например, визуализацию изображений в формате JPEG) в виде модульных библиотек. Поэтому, когда текстовый процессор отображает JPEG-изображения, соответствующие функции запускаются с теми же ограниченными полномочиями, что и сам текстовый процессор. Если в программах визуализации JPEG-изображений имеется брешь, злоумышленник сможет использовать ее только для получения таких же полномочий, как у данного пользователя, что значительно ограничивает масштабы возможного ущерба. В этом преимущество модульных систем, и эти системы ближе к идеалу операционной системы, описанному выше как конструкция из трех сфер (см. раздел "Windows по своей архитектуре является монолитной, а не модульной системой").
Ограничения по умолчанию — свойство модульной архитектуры Linux; едва ли возможно отправить по электронной почте пользователю Linux такое сообщение, которое заразит вирусом весь компьютер. Не имеет значения, насколько неудачно сконструирован почтовый клиент или как именно он прореагирует на вирус — полномочия, установленные для клиента, позволят ему заразить или повредить только файлы своего пользователя. Веб- браузеры, работающие в ОС Linux, не поддерживают такие небезопасные по своей природе объекты, как элементы управления ActiveX, но даже если бы они поддерживались, вредоносный элемент ActiveX смог бы запуститься только с полномочиями того пользователя, который запустил браузер. И в этом случае самый большой вред, который он смог бы принести — это заразить или удалить собственные файлы пользователя.
Даже сервисы, например, веб-серверы, обычно запускаются как пользователи с ограниченными полномочиями. Так, Debian GNU/Linux запускает web- сервер Apache как пользователя "www-data", принадлежащего к группе с тем же именем "www-data". Если злоумышленник на таком хосте получит полный контроль над Apache, он сможет воздействовать только на файлы, принадлежащие пользователю "www-data", то есть на веб-страницы. В свою очередь, MySQL, сервер базы данных SQL-типа, часто используемый вместе с Apache, запускается с полномочиями пользователя "mysql". Даже если Apache и MySQL вместе обслуживают веб-страницы, злоумышленник, получивший контроль над Apache, не будет иметь полномочий, позволяющих использовать уязвимость в Apache для получения контроля над сервером базы данных, потому что сервер базы данных принадлежит другому пользователю. Кроме того, пользователи, ассоциированные с такими сервисами, как Apache, MySQL и т.д., часто устанавливаются с учетными записями, не имеющими доступа к командной строке. Поэтому, если злоумышленник сможет получить права учетной записи пользователя MySQL, он не сможет воспользоваться этой уязвимостью для того, чтобы дать произвольные команды на сервер Linux, поскольку данная учетная запись не может вызывать команды. Напротив, ОС Windows изначально сконструирована таким образом, что всем пользователям и приложениям предоставляется административный доступ ко всем файлам на компьютере. Только постепенно Windows была переработана так, чтобы изолировать пользователей и их действия от остальной системы. Операционная система Windows Server 2003 близка к достижению этой цели, но метод, избранный Microsoft для создания барьера между пользователем и системой, все тот же: широкое использование постоянно меняющихся корректировок существующей конструкции вместо ее фундаментальной переработки на основе новой концепции, в которой во главу угла поставлены реализация многопользовательских возможностей и безопасность.
2. По своей архитектуре Linux является модульной, а не монолитной системой. Linux — это операционная система, сконструированная, в основном, по модульному принципу, от ядра (центрального "мозга" Linux) до приложений. В Linux практически нет нерасторжимых связей между какими-либо компонентами. Не существует единственного браузера, используемого справочными системами или программами электронной почты. В самом деле, нетрудно сконфигурировать большинство программ электронной почты так, чтобы использовать встроенный браузер для отображения HTML-сообщений либо запускать любой нужный браузер для просмотра HTML-документов или перехода по ссылкам, приведенным в тексте сообщения. Следовательно, брешь в одном браузере необязательно представляет опасность для каких-либо других приложений на данном компьютере.
Не все в Linux является модульным. Две наиболее популярные графические среды - KDE и GNOME - в каком-то смысле монолитны по своей архитектуре. По крайней мере, монолитны настолько, что в принципе обновление одной части GNOME или KDE может нарушить работу других частей GNOME или KDE. Но и GNOME, и KDE не до такой степени монолитны, чтобы требовалось использование приложений, разработанных специально для GNOME или KDE. Приложения GNOME или любые другие приложения можно запускать под KDE, а KDE или любые другие приложения — под GNOME.
Ядро Linux поддерживает модульные драйверы, но в значительной мере является монолитным ядром, потому что сервисы в этом ядре взаимозависимы. Все отрицательные последствия монолитности минимизируются тем, что ядро Linux, насколько это возможно, разработано как наименьшая часть системы. Linux почти фанатично придерживается следующего принципа: "Если задача может быть выполнена вне ядра, она должна быть выполнена вне ядра". /* Наглое вранье! В последние годя разроботчики только и делают, что всякую бяку тянут в ядро. Если хотите посмотреть, как должна быть реализована эта концепция – обратитесь, например, к QNX – прим. ред. */ Это означает, что в Linux почти каждая полезная функция ("полезная" означает "воспринимаемая конечным пользователем") не имеет доступа к уязвимым частям системы Linux.
Напротив, ошибки в драйверах графических адаптеров являются частой причиной "синего экрана смерти" в Windows. Это происходит из-за того, что Windows интегрирует графику в ядро, где подобная ошибка может вызвать отказ системы. Не считая нескольких известных исключений (например, коммерческий драйвер графики NVidia), Linux заставляет все графические драйверы функционировать вне ядра. Ошибка в графическом драйвере может вызвать сбой в графическом приложении, но не может вызвать отказ всей системы. В случае такой ошибки достаточно просто перезапустить графическое приложение. Никакой перезагрузки компьютера не требуется.
3. Linux не зависит от RPC-механизма. В большинстве дистрибутивов Linux программы инсталлируются так, что по умолчанию доступ в сеть отключен. Например, MySQL обычно инсталлируется так, что он не ожидает инструкций из сети. Если создать сайт, установив Apache и MySQL на одном и том же компьютере, то для взаимодействия Apache и MySQL не требуется, чтобы MySQL прослушивал сеть. Напротив, SQL Server прослушивает сеть независимо от того, необходимо ли это. Если требуется, чтобы MySQL слушал сеть, эту функцию следует включить вручную, а затем в явном виде определить пользователей и компьютеры, которым разрешен доступ к MySQL.
Даже если Linux-приложения по умолчанию используют сеть, они чаще всего сконфигурированы так, что могут отвечать только локальному компьютеру и игноририруют любые запросы других компьютеров в сети.
В отличие от Windows Server 2003, компьютер с операционной системой Linux останется полностью работоспособным, даже если на нем заблокировать практически все RPC-сервисы, связанные с использованием сети.
4. Серверы Linux идеально подходят для удаленного администрирования. Сервер Linux можно, а часто и нужно, инсталлировать без подключенного монитора и администрировать удаленно. Очень часто такой тип инсталляции идеален для серверов, поскольку при удаленном администрировании сервер не подвергается таким угрозам, как при локальном администрировании.
Например, можно войти в систему на своем настольном компьютере в качестве обычного пользователя с ограниченными полномочиями и администрировать сервер под управлением ОС Linux через административный веб-интерфейс. Даже самая критическая уязвимость в защите браузера сможет воздействовать только на локальную учетную запись пользователя на его настольном компьютере, не затронув сервер.
Возможно, это одно из самых главных отличий Linux от Windows, потому что этот фактор сводит на нет многие критические уязвимости, общие для Linux и Windows, например, уязвимости браузеров Mozilla и Internet Explorer.
продолжение следует.
Николас Петрели (Nicholas Petreley), аналитик по Linux в исследовательской компании Evans Data Corporation, обозреватель "ComputerWorld", "LinuxWorld".
1. Серьезность уязвимостей в системе безопасности, которая оценивается по следующим показателям:
- возможный ущерб (насколько велик вред от использования ОС с незакрытой уязвимостью);
- возможность использования (насколько легко использовать данную уязвимость);
- возможная доступность (какого рода доступ требуется для использования данной уязвимости?).
2. Количество уязвимостей, серьезность которых определяется как rритическая.
Результаты сравнения не оказались неожиданными. Даже по субъективным и заниженным стандартам, применяемым Microsoft, по меньшей мере 38% последних программных коррекций предназначены для ликвидации брешей, которые Microsoft относит к критическим. Только 10% программных коррекций и предупреждений в Red Hat относятся к брешам, имеющим критический уровень серьезности. Приведенные результаты получены при условиях, благоприятных для Microsoft и обоснованно жестких для Red Hat, так как они основаны на критериях Microsoft, а не на используемых нами более строгих показателях безопасности. Если применить наши собственные критерии, то количество критических брешей в Windows Server 2003 возрастет до 50%.
Результаты запроса к базе данных Computer Emergency Readiness Team (CERT) подтвердили наши выводы, сделав разницу еще более значительной. Расположив полученные данные по убыванию серьезности (от более критических к менее критическим), мы обнаружили, что уровень серьезности 39 из первых 40 записей в базе данных CERT для Windows превышает пороговое значение, установленное CERT для серьезных предупреждений. Лишь три из первых 40 записей оказались выше указанного порога в результатах запроса к этой базе данных для ключевого слова «Red Hat». Запрос к базе данных CERT для «Linux» показал, что только шесть из первых 40 записей находятся выше этого порогового значения.
Следует также учесть тот факт, что в списки как для Red Hat, так и для Linux включаются бреши в программном обеспечении, которое функционирует в Windows, а это означает, что такие бреши относятся одновременно и к Linux, и к Windows. Ни одно из предупреждений, связанных с Windows, не относится к программному обеспечению, функционирующему в Linux.
Почему же тогда так много, на первый взгляд, убедительных уверений в том, что операционная система Linux в действительности менее безопасна, чем Windows? Обоснование вывода о меньшей безопасности Linux содержит вопиющие логические несоответствия. Нужно всего лишь чуть внимательнее рассмотреть этот вопрос, чтобы развенчать мифы и найти логические ошибки, лежащие в основе следующих часто повторяемых утверждений. В статье будеь дан также краткий обзор существенных различий в концепциях Windows и Linux, что позволяет понять, почему операционная система Windows более уязвима к атакам как на серверах, так и на настольных компьютерах, и почему Linux является более безопасной системой.
развенчание мифов
Миф 1. Безопасность — вопрос количества: чем меньше инсталляций, тем безопаснее.Пожалуй, чаще всего повторяемый миф при сравнении безопасности Windows и Linux — утверждение, что с ОС Windows случается больше инцидентов, связанных с вирусами, сетевыми червями, троянскими программами и другими проблемами, только из-за того, что злоумышленники предпочитают вмешиваться в работу программного обеспечения, которое имеет наибольшую инсталляционную базу. Это рассуждение приводят в защиту ОС Windows и Windows-приложений. Windows преобладает на настольных компьютерах; именно поэтому на Windows и Windows-приложения направлено большинство атак, и именно поэтому не наблюдаются вирусы, сетевые черви и троянские кони для Linux. Нельзя отрицать, что до некоторой степени это верно, однако отнюдь не бесспорен вывод, который отсюда делается, а именно: Linux и Linux- приложения не являются более безопасными, чем Windows и Windows-приложения, просто Linux — слишком незначительная цель для того, чтобы тратить усилия на организацию атаки.
Это рассуждение легко опровергнуть, если учесть, что самым популярным программным обеспечением для веб-серверов является Apache. Как следует из выполненного компанией Netcraft обзора веб-сайтов за сентябрь 2004 г., 68% сайтов используют веб-сервер Apache /* предполагается, что большинство этих серверов работает под управлением UNIX-подобных ОС, а самая распространенная из них – Linux – прим. ред */ и только 21% сайтов используют Microsoft IIS. Если проблемы с безопасностью возникают из-за того, что злоумышленники нацеливаются на самую обширную инсталляционную базу, то должно наблюдаться больше червей, вирусов и прочих вредоносных программ, нацеленных на Apache и те операционные системы, под управлением которых он функционирует, чем на Windows и IIS. Более того, должно регистрироваться больше атак против Apache, чем против IIS, так как из приведенного выше рассуждения следует, что проблема заключается в количествах, а не в уязвимостях.
Однако в реальности наблюдается обратная картина. В течение долгого времени IIS был главной целью для сетевых червей и других атак, и эти атаки были весьма успешными. Сетевой червь Code Red, который использовал переполнение буфера в сервисе IIS для получения контроля над веб-серверами, заразил около 300 тысяч серверов, и его распространение прекратилось лишь потому, что это было предусмотрено в программном коде данного червя. Воздействие еще одного сетевого червя IISWorm оказалось ограниченным только благодаря тому, что эта программа была плохо написана, а вовсе не из- за успешной защиты IIS.
Да, известны сетевые черви для Apache, например, Slapper (в действительности Slapper использует известную уязвимость в протоколе OpenSSL, а не в Apache). Но сетевые черви для Apache редко становятся сенсацией, поскольку их воздействие очень ограничено и они легко искореняются. На атакуемых сайтах уже были приняты меры, исключающие возможность использования ошибки в OpenSSL. Кроме того, благодаря модульной структуре Linux и *NIX было очень просто очистить и восстановить зараженные сайты. Для этого потребовалось всего несколько команд и не было необходимости в перезагрузке.
Возможно, именно поэтому в рейтинге Netcraft среди 50 web-сайтов, лидирующих по длительности непрерывной работы (промежуток времени между перезагрузками), оказалось 47, использующих Apache. Ни на одном из этих 50 web-сайтов не использовались ни Windows, ни Microsoft IIS. Поэтому, если верно предположение, что злоумышленники атакуют наиболее распространенные программные платформы, то возникает вопрос: почему хакеры так успешно взламывают программное обеспечение и операционную систему, самые популярные среди настольных компьютеров, заражают 300 тысяч серверов IIS, но неспособны нанести подобный ущерб наиболее популярному веб-серверу и типичным для него операционным системам?
Читатели, посещавшие Netcraft, не могут не заметить, что все 50 серверов из списка лучших по длительности непрерывной работы используют какую- либо разновидность BSD, в основном BSD/OS. Только пара из них функционирует под управлением Windows и ни один — под управлением Linux. Самое продолжительное время непрерывной работы среди 50 лидеров составляет 1772 дней подряд или почти 5 лет.
В результате складывается впечатление, что BSD по своей надежности превосходит все остальные операционные системы, однако информация Netcraft, хотя и непреднамеренно, вводит в заблуждение. Netcraft определяет продолжительность непрерывной работы операционных систем по данным, которые регистрируются самими операционными системами. Linux, Solaris, HP-UX и некоторые версии FreeBSD регистрируют не более 497 дней непрерывной работы, после чего счетчики обнуляются, и отсчет начинается заново. Поэтому и кажется, что все веб-сайты, размещенные на компьютерах под управлением Linux, Solaris, HP-UX и, в некоторых случаях, FreeBSD, перезагружаются каждые 497 дней, даже если они функционируют годами. Это объясняет, почему Linux, Solaris и HP-UX не могут продемонстрировать такой же впечатляющий результат по количеству последовательных дней непрерывной работы, как BSD, даже если на самом деле эти операционные системы годами функционируют без перезагрузки. Но это не объясняет, почему среди 50 лидеров мало серверов под управлением ОС Windows. Windows не обнуляет счетчик времени непрерывной работы. Очевидно, сайты под управлением ОС Windows, которые функционировали бы без перезагрузки достаточно долго, чтобы попасть в список 50 лучших – это, скорее, исключение.
Из всего вышесказанного следует вывод, что при оценке количества успешных атак на программное обеспечение решающий фактор — это качество, а не количество.
Миф 2. Открытый код опасен по определению.Впечатляющие данные о продолжительности непрерывной работы, полученные для Apache, позволяют усомниться еще в одном популярном мифе: открытый исходный код (в котором функциональная структура приложений является общедоступной) более опасен, чем патентованный исходный код (в котором функциональная структура является засекреченной), поскольку хакеры могут воспользоваться этим кодом для обнаружения и использования брешей.
Однако факты говорят о другом. Количество предназначенных для ОС Windows эффективных вирусов, программ-шпионов, сетевых червей, троянских и других вредоносных программ огромно, а количество компьютеров, постоянно заражаемых различными комбинациями вышеперечисленного, так велико, что вряд ли поддается исчислению. Вредоносное программное обеспечение "свирепствует" настолько, что для компрометации свежеустановленной, "непропатченной" версии Windows XP после подключения компьютера к Интернету требуется в среднем 16 минут — меньше, чем время, необходимое данной ОС для загрузки и инсталляции программных коррекций, которые позволят защитить этот компьютер.
Еще один пример. Веб-сервер Apache имеет открытый код. Microsoft IIS — патентованный. В этом случае факты опровергают и миф о наибольшей популярности, и миф об опасности открытого кода. Apache — наиболее популярный веб-сервер. Если бы оба эти мифа были правдой, следовало бы ожидать, что Apache и операционные системы, под управлением которых он функционирует, будут чаще подвергаться атакам, чем Microsoft Windows и IIS. На деле же все происходит с точностью до наоборот. Apache занимает почти монопольное положение в списке серверов с наибольшей
продолжительностью непрерывной работы. Очевидно, тот факт, что злоумышленники имеют доступ к открытому коду Apache, не дает им никакого преимущества в организации более успешных атак против Apache, чем против IIS.
Миф 3. Выводы на основании единственной характеристики.Слабость других популярных мифов о большей безопасности Windows по сравнению с Linux в том, что они основаны на единственном показателе — каком-нибудь одном аспекте измерения безопасности. Это верно для любого источника информации, будь то данные компетентного исследования или малообоснованная информация на уровне слухов.
Широко известно утверждение: "Для Linux зарегистрировано больше предупреждений об уязвимостях, чем для Windows, поэтому можно говорить о меньшей безопасности Linux по сравнению с Windows". Не менее распространено и такое: "Время между обнаружением бреши и созданием соответствующей программной коррекции в случае Linux больше, чем в случае Windows, поэтому можно говорить о меньшей безопасности Linux по сравнению с Windows". Второе утверждение совершенно непостижимо. Невозможно объяснить, почему считается, что по такому показателю, как среднее время от момента обнаружения бреши до выпуска соответствующей программной коррекции, Microsoft превосходит какую-либо из конкурирующих операционных систем, не говоря уже о Linux. Компании Microsoft потребовалось семь месяцев (!), чтобы устранить одну из самых серьезных уязвимостей в системе защиты (Microsoft Security Bulletin MS04-007 ASN.1 Vulnerability, компания eEye Digital Security сообщила об этой задержке в информационном бюллетене AD20040210). А ведь еще имеются бреши, о которых Microsoft открыто заявляет, что они никогда не будут ликвидированы. В бюллетене Microsoft Security Bulletin MS03-010 об уязвимости Denial Of Service (отказ в обслуживании) в Windows NT говорится, что эта уязвимость никогда не будет устранена. Позднее компания Microsoft заявила, что не будут устраняться уязвимости в Internet Explorer для всех версий операционных систем, выпущенных ранее Windows XP. В статистическом смысле случай с семью месяцами между обнаружением и устранением ошибки не окажет значительного влияния на среднее время реагирования при условии, что найдется достаточно много примеров чрезвычайно быстрого реагирования, которые скомпенсируют подобные аномалии, если это действительно аномалии. Но стоит включить в выборку только один случай "никогда" — и о статистическом среднем можно забыть навсегда.
Оставив в стороне эту неразрешимую загадку, рассмотрим, есть ли основания полагать, что Linux менее безопасна, чем Windows, потому что среднее время между обнаружением уязвимости и выпуском соответствующей программной коррекции в случае Linux больше, чем в случае Windows. Зададим себе вопрос: "Если прямо сейчас у меня случится сердечный приступ, в какое отделение скорой помощи я предпочту попасть? Туда, где среднее время между регистрацией пациента и оказанием ему помощи самое короткое? Или я предпочту отделение, где это среднее время дольше, но зато пациенты с самыми серьезными диагнозами получают помощь в первую очередь?"
Очевидно, что следует выбрать второе отделение, но вовсе не потому, что из приведенной выше информации ясно, что оно лучше первого. Этот вариант предпочтительнее, потому что он выбран по двум показателям, один из которых особенно важен для вас именно в данный момент. Можно с уверенностью утверждать: мало кто захочет попасть в больницу, о которой известно, что в ней есть шанс умереть от сердечного приступа, ожидая, пока врач закончит вправлять кому-то вывихнутый мизинец — каким бы впечатляющим ни было "среднее время реагирования на запрос о медицинской помощи". Трудность в том, что в приведенном примере недостаточно информации для принятия оптимального решения. Ничего не известно о том, как больница с наименьшим "временем реагирования" определяет, кому из больных следует уделить внимание в первую очередь. Кроме того, неплохо бы иметь информацию о показателе смертности среди больных, нуждающихся в неотложной помощи, о квалификации врачей и т. д.
Очевидно, что для правильного выбора есть только один способ — собрать об окрестных отделениях скорой помощи подробную информацию, т.е. узнать как можно больше важных показателей и найти разумный компромисс между этими показателями. Было бы непростительной безответственностью рекомендовать отделение скорой помощи для случая сердечного приступа, основываясь только на одном показателе, например, на времени реагирования, среднем для всех неотложных случаев, особенно если без труда можно получить другую важную информацию, которая позволит сделать лучший выбор. В той же степени неразумно и безответственно давать рекомендации или принимать серьезное экономическое решение на основании единственного показателя, такого как среднее время между обнаружением бреши и ее устранением для той или иной операционной системы, или такого показателя, как количество предупреждений об уязвимостях для того или иного продукта.
Любой отдельно взятый показатель может ввести в заблуждение, поскольку неясна его значимость. Рассмотрим утверждение, что известно больше предупреждений для программного обеспечения Linux, чем для Windows. Эта статистика бессмысленна, потому что не отвечает на самые важные вопросы. Сколько брешей из зафиксированных всеми предупреждениями об уязвимостях создают реальные угрозы? Насколько серьезны эти угрозы? Насколько вероятно, что их использование причинит серьезный ущерб компьютерам? Ответы на эти вопросы имеют большое значение. Что лучше, операционная система со 100 брешами, из-за которых возможен незначительный ущерб (а то и вовсе никакого) и которыми не сможет воспользоваться никто, кроме локальных пользователей с действующими учетными записями и физическим доступом к компьютеру? Или стоит предпочесть операционную систему с единственной критической брешью, из-за которой любой хакер из Интернета может уничтожить всю информацию на сервере? Ясно, что само по себе количество предупреждений не является значимым показателем, указывающим на большую безопасность одной операционной системы по сравнению с другой.
архитектура Windows и архитектура Linux
У нас пока остался без ответа один важный вопрос. Действительно ли атаки на Windows столь успешны исключительно из-за их многочисленности, или же этот факт объясняется наличием проектных недоработок и неудачных проектных решений Windows?
Значительная часть (если не большинство) вирусов, троянских коней, сетевых червей и других вредоносных программ, заражающих компьютеры с Windows, используют для этого уязвимости в Microsoft Outlook и Internet Explorer. Поэтому можно поставить вопрос по-другому, включив в рассмотрение тот же тип программного обеспечения для Linux (наиболее часто используемые браузеры, программы электронной почты, текстовые процессоры и т. д.): имеет ли Linux столько же уязвимостей в системе безопасности, сколько их имеет Windows?
архитектура Windows
Вирусы, троянские кони и другие вредоносные программы поражают настольные компьютеры с Windows по целому ряду причин, свойственных Windows и чуждых Linux:
1. Windows только недавно эволюционировала от однопользовательской модели к многопользовательской. Критики Linux любят повторять, что Linux — это "устаревшая" технология. Ирония же заключается в следующем: одна из самых больших проблем Windows в том, что именно этой операционной системе никак не удается избавиться от своей "устаревшей" однопользовательской архитектуры.
В течение долгого времени происхождение от однопользовательской системы мешало Windows. Система Windows изначально была разработана так, чтобы обеспечить и пользователям, и приложениям свободный доступ ко всей системе, а это значит, что кто угодно мог скомпрометировать критичную системную программу или файл. Кроме того, это означает, что вирусы, троянские и другие вредоносные программы могли скомпрометировать любую системную программу или файл, потому что Windows не изолировала пользователей и приложения от критичных областей операционной системы. Windows XP стала первой версией Windows, в которой проявились существенные результаты усилий по изолированию пользователей от системы, так что в Windows XP каждый пользователь имеет свои собственные личные файлы и ограниченные системные полномочия. Но из-за этого многие Windows- приложения, разработанные для предыдущих версий, перестали функционировать, поскольку раньше они могли получать доступ и модифицировать программы и файлы, доступ к которым теперь разрешен только администратору. Именно поэтому в Windows XP предусмотрен режим совместимости, то есть режим, который позволяет программам функционировать так, будто они работают в прежней незащищенной однопользовательской среде. Кроме того, именно по этой причине каждая новая версия Windows несет в себе угрозу отказа приложений, работавших в предыдущих версиях. Поскольку Microsoft вынуждена модифицировать Windows, чтобы она "вела себя" как многопользовательская система, новые ограничения выводят из строя приложения, которые функционировали при отсутствии этих ограничений.
Windows XP — это прогресс, но и Windows XP нельзя назвать настоящей многопользовательской системой. Например, Windows XP поддерживает функцию, которую Microsoft называет "Fast User Switching" (быстрое переключение пользователей), она же позволяет двум и более пользователям входить в систему Windows XP на одном компьютере в одно и то же время. Однако есть загвоздка. Это возможно тогда и только тогда, когда данный компьютер не принадлежит какому-либо домену сети Windows. Причина в том, что сеть Microsoft разработана в предположении, что обычно пользователи входят в сеть только со своего собственного компьютера. Microsoft либо не может, либо не желает внести необходимые изменения в операционную систему и "конструкцию" сети, чтобы адаптировать этот сценарий к возможностям Windows XP.
Windows Server 2003 — это следующее приближение к настоящей многопользовательской системе, но даже в Windows Server 2003 не удалось ликвидировать все бреши в системе защиты, унаследованные от однопользовательской системы. Именно поэтому в Windows Server 2003 пришлось отключить использование по умолчанию многих функций веб-браузера (например, ActiveX, написание сценариев и др.). Если бы Microsoft перестроила эти функции для работы в безопасном и изолированном режиме в настоящей многопользовательской среде, они не создавали бы серьезных угроз, перед которыми по-прежнему беззащитна Windows.
2. Windows по своей архитектуре является монолитной, а не модульной системой. Монолитная система — это система, в которой большинство функций интегрировано в единый модуль. Противоположностью такой системе является система, в которой функции распределены по нескольким уровням, причем каждый уровень имеет ограниченный доступ к другим уровням.
Хотя часть недостатков Windows — "наследство" ее исходной однопользовательской архитектуры, другие ее недостатки — прямое следствие обдуманных проектных решений, таких как монолитная архитектура (интегрирование большинства функций в ядро операционной системы). Компания Microsoft фактически вытеснила веб-навигатор Netscape, интегрировав Internet Explorer в свою операционную систему так тесно, что не использовать IE стало практически невозможно. /* да нет же, не использовать IE, конечно, возможно, а вот удалить из системы – очень и очень проблематично – прим. ред. */ Нравится это пользователю или нет, но Internet Explorer вызывается при использовании справочной системы Windows, Outlook и многих других приложений как Microsoft, так и независимых производителей. Конечно, коммерческие интересы Microsoft требуют, чтобы использование каких-либо иных продуктов, кроме Internet Explorer, было крайне затруднительным. Microsoft успешно превращает конкурирующие продукты в ненужные, интегрируя в свою операционную систему все больше и больше сервисов, предоставляемых такими продуктами. Но в результате этого подхода получается монстр из сложным образом взаимодействующих сервисов (то есть, по определению, монолитная система).
Взаимозависимости такого рода имеют два неприятных каскадных побочных эффекта. Во-первых, в монолитной системе каждая брешь в какой-либо одной части системы проявляется во всех сервисах и приложениях, зависящих от этой части системы. Интегрировав Internet Explorer в операционную систему, Microsoft создала систему, в которой любая брешь в Internet Explorer подвергает настольный компьютер с Windows угрозам, реализация которых может нарушить не только работу браузера, но и весьма далеких от него объектов. Следовательно, одна-единственная брешь в Internet Explorer проявляется в бесчисленном множестве других приложений, многие из которых используют Internet Explorer неявным для пользователя образом, что дает этому пользователю ложное ощущение безопасности.
Такая архитектурная модель оказывает намного более глубокое воздействие, чем обычно представляют. Так, в монолитной системе уязвимости в защите оказываются более критичными, чем следовало ожидать.
Проиллюстрировать это поможет простая аналогия. Представим себе идеально устроенную операционную систему, которая состоит из трех сфер: одна — в центре; вторая, большего размера, охватывает первую; а третья сфера охватывает две внутренние. Конечный пользователь "видит" только внешнюю сферу. Это уровень, где пользователь запускает приложения, например, текстовые процессоры. Текстовые процессоры используют необходимые функции, предоставляемые второй сферой, например, средства визуализации графических изображений или форматирования текста. Эта вторая сфера (ее специалисты обычно называют "пользовательскими процессами") не имеет прямого доступа к критичным частям системы. Чтобы выполнить свою работу, она должна запросить разрешение от самой внутренней сферы. Внутренняя сфера выполняет самые важные функции, поэтому имеет непосредственный доступ ко всем критичным частям системы. Она управляет дисками, памятью и всем остальным. Эта сфера называется "ядро" и является сердцем операционной системы.
В случае вышеописанной архитектуры брешь в программах графического отображения не может нанести глобального ущерба компьютеру, потому что функции визуализации не имеют прямого доступа к наиболее критичным частям системы. Даже если пользователь загрузит в текстовый процессор изображение с внедренным вирусом, этот вирус не сможет повредить ничего, кроме собственных файлов пользователя, поскольку функция графического отображения находится вне центральной сферы и не имеет доступа ни к одной из критичных частей системы.
Проблема Windows заключается в том, что в ней не соблюдаются разумные конструкторские принципы разделения функций по соответствующим уровням, описанным выше. Windows вкладывает слишком много функций в ядро, центральную сферу, то есть туда, где можно причинить самый большой ущерб. Например, если интегрировать функции графического отображения в центральную сферу (ядро), эти функции получат возможность повредить всю систему. Таким образом, как только обнаружится брешь в алгоритме графического отображения, чрезмерно интегрированная архитектура Windows облегчит использование этой бреши для получения полного контроля над системой или для разрушения всей системы.
Наконец, монолитная система нестабильна по своей природе. Когда в системе так много взаимосвязей, изменение одной из частей этой системы порождает множество угроз. Единственное изменение в системе может оказать (и обычно оказывает) каскадное воздействие на все сервисы и приложения, которые зависят от этой части системы. Именно поэтому пользователи Windows трепещут при мысли об установке программных коррекций и обновлений. Обновления, исправляющие одну часть Windows, часто нарушают работу других сервисов и приложений. В качестве иллюстрации можно привести следующий факт: для пакета обновлений Windows XP service pack 2 уже составлен постоянно растущий список случаев, когда его установка привела к выходу из строя сторонних приложений. Это естественное явление в монолитной системе — любое изменение в одной части механизма влияет на весь механизм и на все приложения, которые зависят от этого механизма.
3. В Windows слишком широко используется RPC-механизм. Аббревиатура RPC означает "удаленный вызов процедуры" (Remote Procedure Call). RPC — это то, что происходит, когда одна программа отправляет через сеть указание другой программе выполнить какое-либо действие. Например, одна программа может использовать RPC, чтобы дать другой программе указание рассчитать среднюю стоимость чая в Китае и вернуть результат. Удаленным вызовом процедуры этот механизм называется потому, что не имеет значения, функционирует ли "другая программа" на том же компьютере, на соседнем или где-то в Интернете.
RPC-механизмы — это потенциальная угроза безопасности, поскольку их предназначение — позволить компьютерам, находящимся где-то в сети, давать данному компьютеру указания выполнить те или иные действия. Как только обнаруживается брешь в программе, разрешающей использование RPC-механизма, у любого, кто располагает подключенным к сети компьютером, появляется возможность использовать эту брешь, чтобы заставить уязвимый компьютер выполнить какие-либо действия. К сожалению, пользователи Windows не могут заблокировать RPC-механизм, так как Windows использует его, даже если компьютер не подключен к сети. Многие сервисы Windows устроены именно так. В некоторых случаях можно блокировать RPC-порт на межсетевом экране, но Windows так широко использует RPC-механизмы в основных функциях, что подобная блокировка не всегда возможна. Удивительно, но некоторые из наиболее серьезных уязвимостей в Windows Server 2003 — следствие брешей в самих RPC-функциях Windows, а не в приложениях, которые их используют. Самый распространенный способ использовать уязвимость, связанную с RPC-механизмом — атаковать сервис, использующий RPC, а не сам RPC-механизм.
Важно отметить, что RPC-механизмы не всегда необходимы, отчего становится еще непонятнее, почему Microsoft так широко их использует. Предположим, требуется создать веб-сайт, используя два сервера. Один сервер будет работать в качестве сервера базы данных, второй — в качестве веб-сервера. В этом случае серверу базы данных необходимо использовать RPC, потому что веб-сервер находится на отдельном компьютере и должен иметь возможность доступа к серверу базы данных через сетевое подключение. (Даже в этом случае следует сконфигурировать сервер базы данных так, чтобы он "слушал" только данный веб-сервер, но не другие компьютеры). Если же и сервер базы данных, и веб-сервер функционируют на одном компьютере, использование RPC-механизмов на сервере базы данных не только не обязательно, но и нежелательно. Веб-сервер должен иметь прямой доступ к серверу базы данных, потому что они оба функционируют на одном компьютере. Ни технических, ни логических причин подключать к сети сервер базы данных нет, поскольку такое подключение создает лишнюю угрозу безопасности.
Вопрос о серверах баз данных поднят из-за того, что сетевой червь Slammer, один из самых опасных червей, когда-либо существовавших в Интернете, использовал на редкость неуместное применение RPC-подобных сетевых соединений, реализованное Microsoft. За короткое время Slammer заразил так много систем, что Интернет практически перестал функционировать.
Сетевой червь Slammer вызвал хаос, использовав две бреши в Microsoft SQL Server, который является сервером клиент-серверной базы данных. Одна брешь — это самая бесполезная функция Microsoft SQL Server, позволяющая одновременно запустить несколько копий сервера базы данных на одном компьютере. Почему эта функция бесполезна? Если вы незнакомы с работой серверов баз данных, представьте это себе следующим образом. В обычных условиях бессмысленно запускать несколько копий сервера базы данных на одном компьютере, потому что одна копия — это все, что нужно, даже если ее использует множество разных приложений. Потребность в одновременном запуске нескольких серверов баз данных на одном компьютере также вероятна, как потребность в одновременном запуске двух копий Windows XP на одном компьютере. Несколько копий сервера базы данных запускаются не по ошибке исключительно редко, да и то лишь в высокопроизводительных приложениях или для тестирования и разработки.
Кажется, мы поняли, почему Microsoft решила установить по умолчанию именно этот режим функционирования SQL Server. Многие сторонние приложения используют процессор SQL Server по умолчанию. Если бы на компьютере могла функционировать только одна копия SQL Server, то Microsoft пришлось бы разработать удобные средства, позволяющие программе инсталляции обнаружить установленный и функционирующий SQL Server, а затем обеспечить удобный способ инсталляции, интеграции и администрирования особых требований сторонних приложений в своей собственной базе данных и в таблицах, функционирующих на данном сервере. Это очень элегантное решение, минимизирующее используемые ресурсы, поскольку всегда требуется только одна копия SQL Server. Но такой подход потребовал бы большой дополнительной работы со стороны Microsoft или со стороны независимых разработчиков. Намного проще реализовать решение, позволяющее сторонним приложениям не заботиться о том, инсталлирован ли SQL Server. По схеме, реализованной Microsoft, любое стороннее приложение может просто инсталлировать свою собственную копию SQL Server, не беспокоясь о том, установлен ли SQL Server на данном компьютере, какая версия SQL Server инсталлирована, как сконфигурирован существующий SQL Server. Стремясь привлечь независимых разработчиков к использованию SQL Server, Microsoft выбрала принцип наименьшего действия и разработала систему, в которой любое приложение может инсталлировать свою собственную копию SQL Server, которая не взаимодействует с другими копиями SQL Server, функционирующими на том же компьютере. Из-за этого возникла необходимость в запуске несколько копий SQL Server с задействованным RPC-механизмом, который следовало бы использовать как можно реже. Этот наименее затратный подход имел чрезвычайно пагубные последствия. Если бы Microsoft разработала SQL Server так, чтобы он функционировал как единственная копия, не подключенная по умолчанию к сети, то сетевой червь Slammer не нашел бы достаточно компьютеров с работающим SQL Server, чтобы причинить сколько-нибудь значительный ущерб.
Простой способ обеспечить одновременную работу нескольких не мешающих друг другу копий SQL Server — создать RPC-механизм, который сортирует запросы на получение данных таким образом, что, например, приложение-факс запрашивает одну копию SQL Server, а приложение-ежедневник — другую. Ситуация усложняется тем, что и средства разработки Microsoft поддерживают тот же принцип монолитности, который используется в продуктах Microsoft. Поэтому самые разные приложения — программы планирования времени, программное обеспечение для факсимильной связи, системы управления проектами — почти 200 приложений, многие из которых предназначены для настольных систем, используют неоправданно уязвимый процессор SQL Server. В результате сотни тысяч, если не миллионы, людей используют настольные приложения, зависящие от процессора SQL Server с его многочисленными разрешенными сетевыми сервисами, немалая часть которых уязвима к атакам из Интернета. Вряд ли можно придумать лучший способ устроить катастрофу. В результате Slammer смог атаковать огромное количество компьютеров, потому что на всех процессорах SQL Server использование этих функциональных возможностей разрешено по умолчанию. Хотя SQL Server еще не интегрирован в Windows, его повсеместное использование в различных приложениях — от программного обеспечения для факсимильной связи до программ планирования времени — фактически превращает его в часть более крупной монолитной системы, что открывает возможность такой организации атаки, которая характерна для монолитной системы. К сожалению, весьма вероятно, что SQL Server будет тесно интегрирован в File System WinFS, новую перспективную файловую систему Windows, первоначально предназначавшуюся для Longhorn, операционной системы нового поколения. Горячим сторонникам идеи интеграции SQL Server в операционную систему следует помнить об истории с сетевым червем Slammer.
4. Windows фокусируется на знакомом графическом интерфейсе для настольных компьютеров. Компания Microsoft считает знакомый интерфейс Windows главным аргументом в пользу перехода на Windows Server 2003. Цитата с web-сайта компании Microsoft: "Знакомый интерфейс Windows облегчает использование Windows Server 2003. Новые удобные мастера упрощают установку специальных ролей и выполнение обычных задач управления сервером..." Пропагандируя такое использование, Microsoft предлагает администраторам работать с ОС Windows Server 2003 на самом сервере, зарегистрировавшись с полномочиями администратора. В результате администратор Windows становится наиболее уязвимым к брешам в системе защиты, поскольку использование уязвимых программ, таких как Internet Explorer, создает угрозы безопасности сервера.
архитектура Linux
То обстоятельство, что вирусы, троянские и другие вредоносные программы редко могут (если вообще могут) заразить Linux-системы, частично можно объяснить следующими причинами.
1. Linux имеет долгую историю использования тщательно проработанной многопользовательской архитектуры. Linux никогда не была
однопользовательской операционной системой. Поэтому в ней с самого начала заложен принцип изолирования пользователей от приложений, файлов и каталогов, воздействующих на операционную систему в целом. Каждому пользователю предоставляется пользовательский каталог, в котором хранятся все его файлы данных и файлы конфигурации, принадлежащие этому пользователю. Когда пользователь запускает какое-либо приложение (например, текстовый процессор), оно запускается с ограниченными полномочиями данного пользователя. Запущенное пользователем приложение имеет право на запись только в собственный каталог этого пользователя. Оно не может ничего записать в системный файл или даже в каталог другого пользователя, если только администратор явным образом не предоставит данному пользователю такое право.
Еще важнее, что Linux предоставляет почти все функциональные возможности (например, визуализацию изображений в формате JPEG) в виде модульных библиотек. Поэтому, когда текстовый процессор отображает JPEG-изображения, соответствующие функции запускаются с теми же ограниченными полномочиями, что и сам текстовый процессор. Если в программах визуализации JPEG-изображений имеется брешь, злоумышленник сможет использовать ее только для получения таких же полномочий, как у данного пользователя, что значительно ограничивает масштабы возможного ущерба. В этом преимущество модульных систем, и эти системы ближе к идеалу операционной системы, описанному выше как конструкция из трех сфер (см. раздел "Windows по своей архитектуре является монолитной, а не модульной системой").
Ограничения по умолчанию — свойство модульной архитектуры Linux; едва ли возможно отправить по электронной почте пользователю Linux такое сообщение, которое заразит вирусом весь компьютер. Не имеет значения, насколько неудачно сконструирован почтовый клиент или как именно он прореагирует на вирус — полномочия, установленные для клиента, позволят ему заразить или повредить только файлы своего пользователя. Веб- браузеры, работающие в ОС Linux, не поддерживают такие небезопасные по своей природе объекты, как элементы управления ActiveX, но даже если бы они поддерживались, вредоносный элемент ActiveX смог бы запуститься только с полномочиями того пользователя, который запустил браузер. И в этом случае самый большой вред, который он смог бы принести — это заразить или удалить собственные файлы пользователя.
Даже сервисы, например, веб-серверы, обычно запускаются как пользователи с ограниченными полномочиями. Так, Debian GNU/Linux запускает web- сервер Apache как пользователя "www-data", принадлежащего к группе с тем же именем "www-data". Если злоумышленник на таком хосте получит полный контроль над Apache, он сможет воздействовать только на файлы, принадлежащие пользователю "www-data", то есть на веб-страницы. В свою очередь, MySQL, сервер базы данных SQL-типа, часто используемый вместе с Apache, запускается с полномочиями пользователя "mysql". Даже если Apache и MySQL вместе обслуживают веб-страницы, злоумышленник, получивший контроль над Apache, не будет иметь полномочий, позволяющих использовать уязвимость в Apache для получения контроля над сервером базы данных, потому что сервер базы данных принадлежит другому пользователю. Кроме того, пользователи, ассоциированные с такими сервисами, как Apache, MySQL и т.д., часто устанавливаются с учетными записями, не имеющими доступа к командной строке. Поэтому, если злоумышленник сможет получить права учетной записи пользователя MySQL, он не сможет воспользоваться этой уязвимостью для того, чтобы дать произвольные команды на сервер Linux, поскольку данная учетная запись не может вызывать команды. Напротив, ОС Windows изначально сконструирована таким образом, что всем пользователям и приложениям предоставляется административный доступ ко всем файлам на компьютере. Только постепенно Windows была переработана так, чтобы изолировать пользователей и их действия от остальной системы. Операционная система Windows Server 2003 близка к достижению этой цели, но метод, избранный Microsoft для создания барьера между пользователем и системой, все тот же: широкое использование постоянно меняющихся корректировок существующей конструкции вместо ее фундаментальной переработки на основе новой концепции, в которой во главу угла поставлены реализация многопользовательских возможностей и безопасность.
2. По своей архитектуре Linux является модульной, а не монолитной системой. Linux — это операционная система, сконструированная, в основном, по модульному принципу, от ядра (центрального "мозга" Linux) до приложений. В Linux практически нет нерасторжимых связей между какими-либо компонентами. Не существует единственного браузера, используемого справочными системами или программами электронной почты. В самом деле, нетрудно сконфигурировать большинство программ электронной почты так, чтобы использовать встроенный браузер для отображения HTML-сообщений либо запускать любой нужный браузер для просмотра HTML-документов или перехода по ссылкам, приведенным в тексте сообщения. Следовательно, брешь в одном браузере необязательно представляет опасность для каких-либо других приложений на данном компьютере.
Не все в Linux является модульным. Две наиболее популярные графические среды - KDE и GNOME - в каком-то смысле монолитны по своей архитектуре. По крайней мере, монолитны настолько, что в принципе обновление одной части GNOME или KDE может нарушить работу других частей GNOME или KDE. Но и GNOME, и KDE не до такой степени монолитны, чтобы требовалось использование приложений, разработанных специально для GNOME или KDE. Приложения GNOME или любые другие приложения можно запускать под KDE, а KDE или любые другие приложения — под GNOME.
Ядро Linux поддерживает модульные драйверы, но в значительной мере является монолитным ядром, потому что сервисы в этом ядре взаимозависимы. Все отрицательные последствия монолитности минимизируются тем, что ядро Linux, насколько это возможно, разработано как наименьшая часть системы. Linux почти фанатично придерживается следующего принципа: "Если задача может быть выполнена вне ядра, она должна быть выполнена вне ядра". /* Наглое вранье! В последние годя разроботчики только и делают, что всякую бяку тянут в ядро. Если хотите посмотреть, как должна быть реализована эта концепция – обратитесь, например, к QNX – прим. ред. */ Это означает, что в Linux почти каждая полезная функция ("полезная" означает "воспринимаемая конечным пользователем") не имеет доступа к уязвимым частям системы Linux.
Напротив, ошибки в драйверах графических адаптеров являются частой причиной "синего экрана смерти" в Windows. Это происходит из-за того, что Windows интегрирует графику в ядро, где подобная ошибка может вызвать отказ системы. Не считая нескольких известных исключений (например, коммерческий драйвер графики NVidia), Linux заставляет все графические драйверы функционировать вне ядра. Ошибка в графическом драйвере может вызвать сбой в графическом приложении, но не может вызвать отказ всей системы. В случае такой ошибки достаточно просто перезапустить графическое приложение. Никакой перезагрузки компьютера не требуется.
3. Linux не зависит от RPC-механизма. В большинстве дистрибутивов Linux программы инсталлируются так, что по умолчанию доступ в сеть отключен. Например, MySQL обычно инсталлируется так, что он не ожидает инструкций из сети. Если создать сайт, установив Apache и MySQL на одном и том же компьютере, то для взаимодействия Apache и MySQL не требуется, чтобы MySQL прослушивал сеть. Напротив, SQL Server прослушивает сеть независимо от того, необходимо ли это. Если требуется, чтобы MySQL слушал сеть, эту функцию следует включить вручную, а затем в явном виде определить пользователей и компьютеры, которым разрешен доступ к MySQL.
Даже если Linux-приложения по умолчанию используют сеть, они чаще всего сконфигурированы так, что могут отвечать только локальному компьютеру и игноририруют любые запросы других компьютеров в сети.
В отличие от Windows Server 2003, компьютер с операционной системой Linux останется полностью работоспособным, даже если на нем заблокировать практически все RPC-сервисы, связанные с использованием сети.
4. Серверы Linux идеально подходят для удаленного администрирования. Сервер Linux можно, а часто и нужно, инсталлировать без подключенного монитора и администрировать удаленно. Очень часто такой тип инсталляции идеален для серверов, поскольку при удаленном администрировании сервер не подвергается таким угрозам, как при локальном администрировании.
Например, можно войти в систему на своем настольном компьютере в качестве обычного пользователя с ограниченными полномочиями и администрировать сервер под управлением ОС Linux через административный веб-интерфейс. Даже самая критическая уязвимость в защите браузера сможет воздействовать только на локальную учетную запись пользователя на его настольном компьютере, не затронув сервер.
Возможно, это одно из самых главных отличий Linux от Windows, потому что этот фактор сводит на нет многие критические уязвимости, общие для Linux и Windows, например, уязвимости браузеров Mozilla и Internet Explorer.
продолжение следует.
Николас Петрели (Nicholas Petreley), аналитик по Linux в исследовательской компании Evans Data Corporation, обозреватель "ComputerWorld", "LinuxWorld".
Сетевые решения. Статья была опубликована в номере 11 за 2005 год в рубрике save ass…
