Анализ безопасности ОС Linux

Анализ безопасности ОС Linux

Саратовский Государственный Технический Университет

Факультет Управления Социальными Системами

Курсовая работа на тему:

Анализ безопасности ОС Linux

Работу выполнил:

Студент группы ПИН 41

Павлов Михаил:

Проверил:

___________

Саратов

2008

Анализ средств по обеспечению безопасности ОС Linux

Много копий было сломано в спорах о том, действительно ли Linux — более безопасная операционная система,

1. Серьезность уязвимостей в системе безопасности, которая оценивается по следующим показателям:
• возможный ущерб (насколько велик вред от использования ОС с незакрытой уязвимостью?);
• возможность использования (насколько легко использовать данную уязвимость?);
• возможная доступность (какого рода доступ требуется для использования данной уязвимости?).
2. Количество уязвимостей, серьезность которых определяется как Критическая.

Результаты сравнения не оказались неожиданными. Даже по субъективным и заниженным стандартам, применяемым 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 содержит вопиющие логические несоответствия. Нужно всего лишь чуть внимательнее рассмотреть этот вопрос, чтобы развенчать мифы и найти логические ошибки, лежащие в основе следующих часто повторяемых утверждений:

1. Windows подвергается такому количеству атак только потому, что имеет больше инсталляций, чем Linux. Следовательно, Linux была бы столь же уязвима, если бы имела столько же инсталляций.
2. Открытый код по природе своей значительно опаснее, поскольку злоумышленникам легче найти бреши в системе безопасности.
3. Для Linux имеется больше предупреждений об уязвимостях, чем для Windows, следовательно, Linux менее безопасна, чем Windows.
4. В случае операционной системы Linux проходит больше времени между обнаружением бреши и выпуском соответствующей программной коррекции, чем в случае Windows.

Ошибка утверждений 3 и 4 в том, что они игнорируют наиболее важные показатели, позволяющие оценить безопасность одной операционной системы по сравнению с другой. Как будет показано в разделе "Реальные показатели безопасности и серьезности", попытки характеризовать безопасность на основании одного показателя (например, по тому, сколько времени проходит между обнаружением бреши и выходом программной коррекции) не дают значащих результатов.

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

Это рассуждение легко опровергнуть, если учесть, что самым популярным программным обеспечением для web-серверов Интернета является Apache. Как следует из выполненного компанией Netcraft¹ обзора web-сайтов за сентябрь 2004 г., 68% web-сайтов используют web-сервер Apache и только 21% web-сайтов используют Microsoft IIS. Если проблемы с безопасностью возникают из-за того, что злоумышленники нацеливаются на самую обширную инсталляционную базу, то должно наблюдаться больше червей, вирусов и прочих вредоносных программ, нацеленных на Apache и те операционные системы, под управлением которых он функционирует, чем на Windows и IIS. Более того, должно регистрироваться больше атак против Apache, чем против IIS, так как из приведенного выше рассуждения следует, что проблема заключается в количествах, а не в уязвимостях.

¹ Netcraft Web Survey for September 2004 — #"#">². Ни на одном из этих 50 web-сайтов не использовались ни Windows, ни Microsoft IIS. Поэтому, если верно предположение, что злоумышленники атакуют наиболее распространенные программные платформы, то возникает вопрос: почему хакеры так успешно взламывают программное обеспечение и операционную систему, самые популярные среди настольных компьютеров, заражают 300 тысяч серверов IIS, но неспособны нанести подобный ущерб наиболее популярному web-серверу и его операционным системам?

² Netcraft Top 50 Servers With Longest Uptime (результаты могут отличаться от приведенных, так как информация обновляется ежедневно) — #"#">³.

³ Unpatched PC "Survival Time" Just 16 Minutes, Gregg Keizer, TechWeb News #"#" target="_blank">Таб.1) — следствие брешей в самих RPC-функциях Windows, а не в приложениях, которые их используют. Самый распространенный способ использовать уязвимость, связанную с RPC-механизмом — атаковать сервис, использующий RPC, а не сам RPC-механизм.

Важно отметить, что RPC-механизмы не всегда необходимы, отчего становится еще непонятнее, почему Microsoft так широко их использует. Предположим, требуется создать web-сайт, используя два сервера. Один сервер будет работать в качестве сервера базы данных, второй — в качестве web-сервера. В этом случае серверу базы данных необходимо использовать RPC, потому что web-сервер находится на отдельном компьютере и должен иметь возможность доступа к серверу базы данных через сетевое подключение. (Даже в этом случае следует сконфигурировать сервер базы данных так, чтобы он "слушал" только данный web-сервер, но не другие компьютеры). Если же и сервер базы данных, и web-сервер функционируют на одном компьютере, использование RPC-механизмов на сервере базы данных не только не обязательно, но и нежелательно. Web-сервер должен иметь прямой доступ к серверу базы данных, потому что они оба функционируют на одном компьютере. Ни технических, ни логических причин подключать к сети сервер базы данных нет, поскольку такое подключение создает лишнюю угрозу безопасности.

Вопрос о серверах баз данных поднят из-за того, что сетевой червь Slammer, один из самых опасных червей, когда-либо существовавших в Интернете, использовал на редкость неуместное применение RPC-подобных сетевых соединений, реализованное Microsoft. За короткое время Slammer заразил так много систем, что Интернет практически перестал функционировать.

Сетевой червь Slammer вызвал хаос, использовав две бреши в Microsoft SQL Server, который является сервером клиент-серверной базы данных SQL-типа. Одна брешь — это самая бесполезная функция 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.

Windows фокусируется на знакомом графическом интерфейсе для настольных компьютеров

Компания Microsoft считает знакомый интерфейс Windows главным аргументом⁵ в пользу перехода на Windows Server 2003. Цитата с web-сайта компании Microsoft: "Знакомый интерфейс Windows облегчает использование Windows Server 2003. Новые удобные мастера упрощают установку специальных ролей и выполнение обычных задач управления сервером..."

⁵ Top 10 Benefits of Windows Server 2003 — #"#" target="_blank">#"#" target="_blank">Таб. 1 содержится информация об уязвимостях из 40 последних программных коррекций системы защиты, выпущенных компанией Microsoft⁶.

⁶ Microsoft Security Bulletin, Current Downloads (результаты могут отличаться от приведенных, так как информация регулярно обновляется) — #"#">⁷:

⁷ Default Settings Different on Windows Server 2003 Эти настройки перечисляются на нескольких страницах в разделе "Frequently Asked Questions, What is Internet Explorer Enhanced Security Configuration?" Вот одна из таких страниц: #"#" target="_blank">Таб. 1) включены бреши, уровень серьезности которых ограничен в соответствии с полномочиями пользователя. Эти случаи отмечены в таблице: в столбце "Полномочия" указано "Пользователь". Но поскольку Windows Server 2003 — это сервер, то очевидно, что большинство пользователей, непосредственно работающих на компьютере под управлением Windows Server 2003, будут администраторами. Даже если предположить, что все станут использовать оптимальные приемы работы на настольном компьютере, очевидно, что администраторы Windows Server 2003 входят в систему с полномочиями администратора. Поэтому в тех случаях, когда серьезность брешей "ограничивается" полномочиями пользователя, большую часть времени уровень серьезности фактически не уменьшается, так как пользователь будет иметь полномочия администратора. В качестве примера можно привести брешь, описанную в Microsoft Security Bulletin MS04-015. По указанной выше причине эта брешь заслуживает оценки Критическая, а не Важная. Парадоксально, но подобные бреши в Linux заслуживают понижения оценки, потому что Linux не предлагает администраторам работать в графической среде непосредственно на сервере.

Приняв во внимание все обстоятельства, следует оценить как Критические еще по меньшей мере пять уязвимостей. Это означает, что по показателям, описанным в предыдущих разделах, 50% перечисленных брешей оцениваются как Критические. Если уязвимость должна иметь оценку Критическая с учетом того, что администратор, скорее всего, изменит те настройки по умолчанию, благодаря которым Microsoft понизила уровень серьезности, то этот факт отмечается в скобках. Но при общем сравнении эти уязвимости не рассматривались как Критические. Комментарий в скобках показывает, что Microsoft преднамеренно недооценивает серьезность данной бреши на основании необоснованного допущения — настройки по умолчанию, установленные в Windows Server 2003, существенно меняют ситуацию.

Таблица 1. Программные коррекции и уязвимости Microsoft Windows Server 2003

Программные коррекции и уязвимости Red Hat Enterprise Linux AS v.3

В Таб. 2 содержится информация об уязвимостях из 40 последних программных коррекций системы защиты, выпущенных компанией Red Hat.

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

Из 40 уязвимостей только четыре оценены как Критические. Это означает, что 10% из 40 последних обновлений имеют серьезность Критическая.

Но если принять во внимание особенности программного обеспечения, к которому относятся две из четырех уязвимостей, можно утверждать, что серьезность этих двух уязвимостей не следует оценивать так высоко. Эти две уязвимости связаны с программой Ethereal. Ethereal — это одно из нескольких доступных средств контроля сетевых компонентов и прослушивания сети ("sniffer"). Программа Ethereal запускается при необходимости, а не в качестве постоянного сервиса, поэтому вероятность того, что она будет работать в момент, когда кто-то пытается воспользоваться ее уязвимостью, крайне мала. Если по этой причине понизить серьезность указанных уязвимостей до Важная, то только 5% из 40 последних предупреждений следует считать Критическими.

Уязвимости в сервисах IPSEC и Kerberos более обосновано оценены как Критические, поскольку эти сервисы функционируют на постоянной основе.

Лишь немногие уязвимости позволяют злоумышленнику действовать на уровне администратора. Однако даже в этих редких случаях, как правило, имеются факторы, уменьшающие опасность. Например, уязвимость в Samba (июль 22, 2004, RHSA-2004:259-23) можно использовать только в том случае, если кто-либо сконфигурирует inetd (через файл hosts.allow) так, что известному пользователю и компьютеру разрешается доступ к этому сервису. Если система сконфигурирована правильно, то никто, кроме авторизованного известного пользователя, не может получить доступ к программе конфигурации Samba, чтобы использовать данную уязвимость. В противном случае серьезность этой уязвимости следовало бы оценить как Критическую. Для использования других брешей, позволяющих получить административный доступ, также необходимо быть известным пользователем с действующим идентификатором. Это уменьшает угрозу и снижает серьезность, поскольку значительно увеличивается вероятность поимки злоумышленника.

Результаты запросов к базе данных CERT по уязвимостям

Американская группа Computer Emergency Readiness Team (CERT) использует свой собственный набор показателей для оценки серьезности брешей в защите. Результат выражается числом в диапазоне от 0 до 180, причем значение 180 означает самую серьезную уязвимость. Шкала является нелинейной. Иначе говоря, уязвимость с оценкой 100 не является в два раза более серьезной, чем уязвимость с оценкой 50.

CERT считает любую уязвимость с оценкой 40 или выше достаточно серьезной, чтобы включить ее в специальное техническое предупреждение, выпускаемое CERT Advisory и US-CERT.

Мы сделали запросы к базе данных CERT по ключевым словам "Microsoft", "Red Hat" и "Linux". К сожалению, средства web-поиска на сайте CERT не позволяют обеспечить в полной мере желаемую детализацию и долговечность результатов. Особенно это верно для результатов поиска по "Red Hat" и "Linux". Результаты поиска по "Linux" включают в себя несколько уязвимостей Oracle, общих для Linux, UNIX и Windows. Результат по "Red Hat" с данными о самой серьезной уязвимости даже не содержит среди подробностей указания на Red Hat как на уязвимую систему. Результаты поиска по "Microsoft" представляются вполне точными, так как и в подробностях, и в самих записях указаны бреши именно в программном обеспечении Microsoft. Вследствие этого результаты несколько искажаются не в пользу Linux и Red Hat. Тем не менее, даже если принять эти результаты, проигнорировав искажение для Linux и Red Hat, все равно получается, что большинство записей в базе данных CERT относится к Microsoft, и эти записи содержат информацию о самых серьезных брешах.

Запрос к базе данных CERT по слову "Microsoft" дал 250 результатов, причем две первые записи описывают бреши с показателем серьезности 94,5. 39 записей описывают бреши с серьезностью 40 или выше. Средняя оценка серьезности по 40 первым записям — 54,67. (Усреднение проведено по 40 записям, а не по 50 или больше, так как поиск для "Red Hat" дал только 46 записей).

Запрос к базе данных CERT по слову "Red Hat" дал 46 результатов. Первая запись описывает брешь с показателем серьезности 108,16. Только три записи (против 39 для Microsoft) содержат оценку серьезности 40 или выше. Среднее значение серьезности по первым 40 записям — 17,96.

Запрос к базе данных CERT по слову "Linux" дал 100 результатов. Первая запись описывает брешь с показателем серьезности 87,72. Только шесть записей содержат оценку серьезности 40 и выше. Среднее значение серьезности по первым 40 записям — 28,48.

Не стоило ожидать, что эти результаты совпадут с результатами нашего анализа по последним программным коррекциям. CERT использует другие критерии отбора, другой порядок дат, к тому же CERT не ограничивается только Windows Server 2003 и Red Hat Enterprise Linux AS v.3. Но результаты запросов к базе данных CERT отражают тот факт, что бреши в системе защиты Windows оказываются серьезными гораздо чаще, чем бреши в Linux, что соответствует нашим выводам.

Список литературы:

www.bugtraq.ru

www.xakep.ru

www.wikipedia.org

etc…