Windows и Linux: что безопаснее?
продолжение, начало в СР № 11’2005.
реальные показатели безопасности и серьезности
Чтобы надлежащим образом оценить риски, связанные с выбором операционной системы для какой-либо определенной задачи, необходимо рассмотреть множество показателей. Иногда они действуют кумулятивно, в других случаях — компенсируют друг друга.
Существуют три очень важных фактора риска, которые существенно зависят друг от друга. Комбинация этих трех факторов решающим образом влияет на общую серьезность той или иной бреши в системе защиты. Такими элементами показателя общей серьезности являются: возможный ущерб, возможность использования и возможная доступность.
элементы показателя общей серьезности
Возможный ущерб любой обнаруженной уязвимости показывает, какой вред может быть нанесен в результате ее использования злоумышленником. Уязвимость, позволяющая раскрыть все пароли администраторов, имеет высокий показатель возможного ущерба. Этот показатель для бреши, в результате использования которой начинает мерцать экран, обычно намного ниже, он возрастает только в том случае, если это конкретное повреждение трудно исправить.
Возможность использования показывает, насколько просто или сложно использовать данную уязвимость, потребуется ли высокая квалификация в программировании или эту уязвимость сможет использовать любой человек с самыми элементарными знаниями в указанной области.
Возможная доступность показывает, какой уровень доступа необходим для использования данной уязвимости. Если любой начинающий хакер (тот, кого обычно называют "script kiddie") из Интернета может использовать брешь на сервере, защищенном межсетевым экраном, то эта брешь имеет очень высокую возможную доступность. Если же использовать брешь сможет только сотрудник компании, имеющий действующие регистрационное имя и пароль, причем исключительно с компьютера, находящегося в здании компании, то возможная доступность этой бреши значительно меньше.
показатель общей серьезности и взаимосвязь между тремя факторами риска
Один или несколько из вышеперечисленных факторов риска могут оказать решающее воздействие на общую серьезность ошибки. Рассмотрим следующую ситуацию. Руководитель информационной службы компании, занимающейся электронной коммерцией через веб-сайт, узнает от аналитика по безопасности, что обнаружена брешь в операционной системе, под управлением которой функционируют серверы компании. Злоумышленник может использовать эту брешь, чтобы удалить всю информацию с дисков на всех серверах, используемых компанией.
Возможный ущерб: последствия от этой бреши катастрофичны.
Хуже того, аналитик добавляет, что с технической точки зрения эту брешь использовать тривиально просто. Стало быть, возможность использования имеет критический уровень.
Пора нажимать аварийную кнопку, не так ли? Но предположим, что аналитик добавляет еще несколько слов. Использовать эту брешь может только тот, у кого есть ключ от серверной комнаты, потому что эта данная уязвимость требует физического доступа к компьютерам. Этот единственный ключевой показатель, простите за каламбур, радикально изменяет общую серьезность угрозы, порожденной данной конкретной брешью. Крайне низкая возможная доступность переводит стрелку на шкале серьезности с "тревога!" на "под контролем".
Наоборот, другая уязвимость может быть доступна любому начинающему хакеру в Интернете, но по-прежнему будет иметь незначительную серьезность, если возможный ущерб от этой бреши является несущественным.
Возможно, теперь более понятно, почему обманчива, если не совершенно безответственна, методика оценки безопасности по одному-единственному показателю, например, по количеству предупреждений об уязвимостях. В самом крайнем случае следует рассмотреть также указанные три фактора риска. Какая операционная система заслуживает больше доверия — с сотней брешей пренебрежимо малой серьезности или же с десятком брешей чрезвычайно высокой серьезности (использование бреши ведет к катастрофе)? Если при оценке не учитывать общую серьезность брешей, то подсчет их количества в лучшем случае не имеет никакого значения, в худшем — вводит в заблуждение.
исключение из правила
Показатель общей серьезности имеет три упомянутых "главных" компонента. Выше же было показано, как низкий возможный ущерб или низкая возможная доступность могут практически свести на нет другие факторы риска, какими бы высокими они ни были. Возможность использования — исключение из этого правила. Брешь, для использования которой требуется высококвалифицированный специалист, значительно меньше компенсирует высокий показатель возможного ущерба или возможной доступности.
Объясняется это просто. Если для использования бреши необходимо попасть в комнату с компьютерами, то дело не только в том, что это трудно, но и в том, что любая попытка проникнуть в эту комнату увеличивает для злоумышленника риск быть пойманным. И именно поэтому брешь, которую может использовать только сотрудник компании, менее серьезна, чем брешь, которую может использовать любой начинающий хакер из Интернета. В первом случае риск быть пойманным намного выше, чем во втором.
С другой стороны, анонимные злоумышленники-программисты весьма заурядной квалификации могут в течение нескольких недель или месяцев разрабатывать программу, позволяющую использовать какую-либо брешь в защите, практически не рискуя при этом быть пойманными. Единственная важная задача, стоящая перед таким злоумышленником, — активировать вредоносную программу так, чтобы невозможно было отследить ее автора.
Уже поверхностное знакомство с современным состоянием вредоносного программного обеспечения показывает самоочевидность этого исключения. Мало кто воспользуется базукой, чтобы проложить себе путь в машинный зал и "взломать" находящиеся там серверы. Но существует бесчисленное множество троянских программ, сетевых червей и вирусов, которые по-прежнему заражают множество компьютеров, и одна из причин в том, что программисты, талантливые и не очень, считают признаком профессионализма умение преодолеть технические трудности написания вредоносного кода или переработки вредоносного кода, написанного другими. Очевидно, что технические трудности необязательно компенсируют высокую опасность бреши, вызванную другими причинами.
применение показателя общей серьезности
Только оценив общую серьезность конкретной бреши, можно перейти к осмыслению таких показателей, как "сколько предупреждений об уязвимости существует для Windows по сравнению с Linux" или "сколько времени проходит между обнаружением и исправлением ошибки в случае Windows и в случае Linux".
Предположим, для одной операционной системы зарегистрировано намного больше предупреждений об уязвимостях, чем для другой. Этот показатель имеет смысл только в одном случае — если для данной системы имеется также больше предупреждений об уязвимостях с высоким уровнем общей серьезности. Одно дело, если довольно часто случаются разные мелкие неприятности, не представляющие практически никакой опасности, и совсем другое — когда регулярно обнаруживаются пусть и немногочисленные, но такие бреши, которые ставят под удар всю компанию.
Предположим, что для некоторой операционной системы зафиксировано более короткое время между обнаружением бреши и выходом соответствующей программной коррекции. И в этом случае показатель имеет смысл только тогда, когда это время относится к брешам с высокой общей серьезностью. Одно дело — несколько месяцев ждать коррекции для бреши, использование которой может нанести незначительный ущерб небольшому количеству компьютеров или даже совсем не причинить никакого вреда. И совсем другое дело — ожидать месяцами коррекции для бреши, использование которой может поставить под удар всю компанию.
Теперь перейдем непосредственно к способам оценки каждого из перечисленных показателей.
возможная доступность
Данный показатель учитывает меры, которые необходимо принять для получения доступа к компьютеру с целью использовать уязвимости в системе защиты. Обычно такие меры попадают в одну из перечисленных ниже категорий. На практике реальный порядок этих категорий может меняться, но приведенный список может оказаться удобным ориентиром. Кроме того, следует заметить, что существует несколько экзотических сложных случаев, которые в приведенном списке не рассматриваются. Например, закрытая программной коррекцией брешь в Windows Server 2003 сама по себе была не очень доступна, но она позволяла злоумышленнику сделать систему незащищенной перед серьезными угрозами. То есть это было одно из звеньев в цепочке уязвимостей. Категории в списке перечислены в порядке возрастания их серьезности.
1. Необходим физический доступ к компьютеру, но не требуется наличия действующей учетной записи пользователя.
2. Необходим физический доступ к компьютеру и требуется действующая учетная запись пользователя. /* Я бы, вообще-то поменяла пункты 1 и 2 местами, поскольку формальная логика подсказывает, что наличие двух обязательных условий в любом случае боллее труднодостижимая задача. Однако автор – барин, оставляем все как есть :) – прим. ред. */
3. Необходима действующая учетная запись пользователя, но не нужен физический доступ к атакуемому компьютеру. Достаточно доступа по локальной сети (из корпоративной сети компании).
4. Необходима действующая учетная запись пользователя, но не нужен физический доступ к атакуемому компьютеру. Атакуемый компьютер доступен через Интернет с удаленного компьютера.
5. Можно использовать брешь удаленно, через Интернет, не имея действующей учетной записи пользователя на атакуемом компьютере, но невозможно достичь бреши напрямую. Существует еще один барьер, например, маршрутизатор или межсетевой экран. Для этой категории трудно найти надлежащее место при перечислении по уровню серьезности, поскольку правильно сконфигурированный межсетевой экран может обеспечить стопро-центную защиту, но не всегда. Плохо сконфигурированный межсетевой экран может вообще не обеспечивать никакой защиты.
6. Можно использовать брешь удаленно, через Интернет, не имея действующей учетной записи пользователя на атакуемом компьютере, но невозможно достичь бреши напрямую. Существует еще один, более трудный для преодоления барьер. Этим барьером может быть другая программа (например, брешь существует в Microsoft SQL Server, но для ее использования необходимо внедрить элемент управления ActiveX или Javascript в веб-страницу, доступную через Microsoft Internet Information Server). В некоторых случаях для получения непрямого доступа необходимо вовлечь в этот процесс пользователя. Например, придется разослать по электронной почте сообщения, которые направят пользователей на web-страницу, содержащую вредоносный элемент управления или код. Широко используется способ, когда пользователю предлагается открыть файл, вложенный в электронное письмо. Серьезность этой категории меняется в зависимости от того, насколько искусно это вовлечение замаскировано под невинное действие.
7. Использовать брешь можно удаленно, через Интернет, не имея действующей учетной записи пользователя на атакуемом компьютере, но невозможно достичь бреши напрямую. Тем не менее, брешь используется косвенно, но автоматически. Например, брешь в операционной системе Windows используется немедленно и автоматически, как только пользователь открывает электронное письмо с помощью программы Outlook.
8. Использовать брешь можно удаленно, через Интернет, просто отправив через сеть информацию на атакуемый компьютер. Например, уязвимость типа "отказ в обслуживании" (DoS) можно использовать просто отправив специальные сетевые пакеты на атакуемый web-сайт, что сделает этот веб-сайт недоступным для других пользователей Интернета.
возможность использования
Этот показатель учитывает технические трудности, которые необходимо преодолеть, чтобы использовать брешь в защите. Обычно эти трудности попадают в одну из перечисленных ниже категорий. Категории перечислены в порядке возрастания их серьезности (на практике реальный порядок этих категорий может меняться, но приведенный список может оказаться удобным ориентиром).
1. Брешь существует, но еще не обнаружена. Для использования этой бреши необходимы либо исключительная компетентность, либо счастливый случай.
2. Для использования бреши необходимы высокая квалификация в программировании и глубокое знание операционной системы, но о существовании этой бреши известно недостаточно широко, из-за чего маловероятно, что ее используют многие нарушители.
3. О существовании бреши известно, и для ее использования необходимы высокая квалификация в программировании и глубокое понимание того, как функционируют атакуемые программное обеспечение и операционная система.
4. Для использования бреши необходима высокая квалификация в программировании, но уже создан вирус, троянская программа или сетевой червь, которые могут служить основой для атаки. Программисту требуется только модифицировать этот код, чтобы использовать новую брешь или сделать данный вирус более опасным.
5. Для создания кода, использующего брешь, необходима высокая квалификация в программировании, но подходящий код уже существует, и достаточно средней квалификации в программировании, чтобы усовершенствовать или модифицировать этот код так, что он будет использовать существующую брешь или "будущие" бреши.
6. Для использования бреши достаточно средней или начальной квалификации в программировании либо же элементарного знания компьютера. 7. Не имеет значения, насколько трудно использовать брешь, поскольку вся работа по созданию средств для использования этой бреши уже проделана, а вредоносный код сделан общедоступным для его применения новичками.
8. Кто угодно может использовать брешь, введя простой текст в командной строке или указав URL в веб-браузере.
возможный ущерб
Оценить этот показатель труднее всего. Требуется определить, по крайней мере, два различных набора категорий. Во-первых, надо учесть, какой вред причинит использование бреши приложениям или компьютерам. Во-вторых, необходимо оценить возможный ущерб с точки зрения последствий для всей компании. Например, в ситуации, когда брешь позволяет нарушителю прочитать неопубликованные веб-страницы. Вред от этого незначителен, если на компьютере не хранится конфиденциальная информация. Но если неопубликованная веб-страница содержит какую-либо конфиденциальную информацию, например, номера кредитных карт, то общий возможный ущерб может быть очень большим, и это при том, что возможный технический ущерб минимален. Ниже приводятся (в порядке возрастания серьезности) наиболее важные факторы, которые следует учитывать при оценке возможного технического ущерба в результате использования какой-либо конкретной бреши.
1. Брешь влияет только на производительность другого компьютера, но не настолько, чтобы он перестал отвечать на запросы.
2. Брешь влияет только на собственные программы или файлы нарушителя, но не затрагивает файлы или программы других пользователей.
3. Брешь делает незащищенной информацию в файлах других пользователей, но не учетную запись администратора или системные файлы.
4. Брешь позволяет нарушителю просматривать, изменять или удалять пользовательские файлы. Она не дает возможности просматривать, изменять или удалять файлы администратора или системные файлы.
5. Брешь позволяет нарушителю просматривать критичную информацию либо путем исследования сетевого трафика, либо путем доступа с правами "только чтение" к файлам администратора или к системным файлам.
6. Брешь позволяет нарушителю получить некоторые, но не все, полномочия административного уровня, возможно, в ограниченном окружении.
7. Брешь позволяет нарушителю вызвать отказ системы или каким-то иным путем заставить ее не отвечать на обычные запросы. Это — типичная атака "отказ в обслуживании". Однако нарушитель фактически не может получить контроль над компьютером, за исключением того, что компьютер перестанет отвечать на запросы.
8. Брешь позволяет нарушителю изменить или удалить все привилегированные файлы и информацию. Нарушитель может получить полный контроль над атакуемой системой и фактически причинить такой же ущерб, какой способен нанести полностью авторизованный системный администратор.
уровень общей серьезности
С учетом описанных выше трех факторов общая серьезность угроз может изменяться от минимальной до катастрофической. Рассмотреть все перестановки не представляется возможным, но несколько примеров могут оказаться полезными. Эти примеры основываются на категориях возможного ущерба в сочетании с различными категориями возможной доступности и возможности использования.
1. Если анонимный злоумышленник из Интернета сумеет снизить производительность компьютеров компании, то оценка последствий может варьироваться от "мелкая неприятность" до "разрушительный удар по финансам" в зависимости от того, насколько критичной является производительность системы для деятельности компании.
2. Атака на собственную учетную запись является бессмысленной, но такая саморазрушительная деятельность может создать для ИТ-подразделения лишнюю работу по восстановлению.
3. Потенциальная серьезность бреши, позволяющей просматривать только файлы работающего в том же здании сослуживца, минимальна, даже если эту брешь тривиально просто использовать. Уровень серьезности возрастает, когда файлы этого сослуживца содержат конфиденциальную информацию, и уменьшается, если велика вероятность поимки нарушителя. С другой стороны, если просматривать конфиденциальные файлы в сети компании может любой злоумышленник из Интернета (высокая возможная доступность), общая серьезность бреши резко возрастает.
4. Если брешь позволяет нарушителю изменять или удалять файлы работающего в том же здании сослуживца, серьезность этой бреши тем меньше, чем регулярнее выполняется в компании резервное копирование и чем больше вероятность поимки нарушителя. Если нарушитель может изменять файлы учетной записи пользователя на удаленном компьютере, то серьезность меняется в зависимости от важности этой учетной записи и предоставляемого ею сервиса. Например, серьезность может варьироваться от незначительного искажения веб-страниц до их полного удаления.
дисбаланс приложений
В дебатах о превосходстве одной операционной системы над другой часто упускается из виду, что уязвимости в системе защиты почти всегда коренятся в приложениях. Данное обстоятельство создает определенные трудности при сравнении Windows и Linux, потому что эти две системы находятся в неравном положении с точки зрения переносимости и доступности приложений.
С одной стороны, большинство популярных приложений для Microsoft Windows составляют приложения Microsoft, и они запускаются только под Windows. Когда обнаруживается брешь в Microsoft Exchange, можно обоснованно полагать, что эта проблема затронет только клиентов Windows. Microsoft Exchange не функционирует ни в Linux, ни в Solaris, ни где-либо еще, кроме Windows.
С другой стороны, веб-сервер Apache чаще всего ассоциируется с Linux или другими *NIX-системами, но Apache функционирует и под управлением Windows. Поэтому, сравнивая общую безопасность Windows и Linux, можно ли считать, что брешь в Apache — это дефект только Linux? Или она негативно сказывается и на Linux, и на Windows?
Еще больше усложняет проблему то, что известно несколько случаев, когда брешь в Apache почти (или даже совсем) не опасна для Linux, но является серьезной уязвимостью в Windows. Обратная ситуация встречается крайне редко, если вообще встречается. /* Применительно к Apache точно не скажу, хотя мне кажется, такая ситуация может иметь место. Но с другими кросс-платформенными продуктами сплошь и рядом бывает, что уязвимость может проявиться только под *NIX-системами. – прим. ред. */ Следует ли понижать оценку общей безопасности Windows потому, что эта система более подвержена неблагоприятному воздействию, чем Linux, при использовании программного обеспечения, которое обычно ассоциируется с Linux? Вопрос о том, учтен ли какой-либо из этих факторов при сравнении общей безопасности Windows и Linux, ни в коем случае нельзя оставлять без внимания.
настройка и администрирование
Наконец, различие в подходе к настройке и администрированию серверов в Linux и в Windows, как уже отмечалось, возможно, является самым важным различием между этими двумя операционными системами.
Windows предлагает использовать знакомый интерфейс, что означает администрирование ОС Windows Server 2003 на самом сервере. Linux не полагается на локальное использование графического интерфейса и не поощряет этого отчасти потому, что функционирование графической среды на сервере — это необоснованная трата ресурсов, а отчасти потому, что от этого возрастают угрозы безопасности сервера. Так, любой сервер, предлагающий использовать графический интерфейс на компьютере сервера, предлагает также выполнять на сервере похожие операции, например, использовать веб- навигатор. В результате сервер подвергается угрозам, порожденным уязвимостями в защите браузера. Любой сервер, побуждающий пользователя к удаленному администрированию, защищен от подобных угроз. Если администрирование сервера Linux осуществляется удаленно, через учетную запись пользователя на рабочей станции, то брешь в браузере создает угрозу только этой удаленной рабочей станции, а не серверу. Именно поэтому брешь в защите браузера потенциально опаснее для Windows Server 2003, чем для Red Hat Enterprise Server AS.
В следующей, заключительной, части статьи будут представлены списки реальных уязвимостей под обе осбуждаемые платформы с оценкой серьезности каждой уязвимости, ну и, конечно, будут сделаны какие-то выводы.
продолжение следует.
Николас Петрели (Nicholas Petreley), аналитик по Linux в исследовательской компании Evans Data Corporation, обозреватель "ComputerWorld", "LinuxWorld".
реальные показатели безопасности и серьезности
Чтобы надлежащим образом оценить риски, связанные с выбором операционной системы для какой-либо определенной задачи, необходимо рассмотреть множество показателей. Иногда они действуют кумулятивно, в других случаях — компенсируют друг друга.
Существуют три очень важных фактора риска, которые существенно зависят друг от друга. Комбинация этих трех факторов решающим образом влияет на общую серьезность той или иной бреши в системе защиты. Такими элементами показателя общей серьезности являются: возможный ущерб, возможность использования и возможная доступность.
элементы показателя общей серьезности
Возможный ущерб любой обнаруженной уязвимости показывает, какой вред может быть нанесен в результате ее использования злоумышленником. Уязвимость, позволяющая раскрыть все пароли администраторов, имеет высокий показатель возможного ущерба. Этот показатель для бреши, в результате использования которой начинает мерцать экран, обычно намного ниже, он возрастает только в том случае, если это конкретное повреждение трудно исправить.
Возможность использования показывает, насколько просто или сложно использовать данную уязвимость, потребуется ли высокая квалификация в программировании или эту уязвимость сможет использовать любой человек с самыми элементарными знаниями в указанной области.
Возможная доступность показывает, какой уровень доступа необходим для использования данной уязвимости. Если любой начинающий хакер (тот, кого обычно называют "script kiddie") из Интернета может использовать брешь на сервере, защищенном межсетевым экраном, то эта брешь имеет очень высокую возможную доступность. Если же использовать брешь сможет только сотрудник компании, имеющий действующие регистрационное имя и пароль, причем исключительно с компьютера, находящегося в здании компании, то возможная доступность этой бреши значительно меньше.
показатель общей серьезности и взаимосвязь между тремя факторами риска
Один или несколько из вышеперечисленных факторов риска могут оказать решающее воздействие на общую серьезность ошибки. Рассмотрим следующую ситуацию. Руководитель информационной службы компании, занимающейся электронной коммерцией через веб-сайт, узнает от аналитика по безопасности, что обнаружена брешь в операционной системе, под управлением которой функционируют серверы компании. Злоумышленник может использовать эту брешь, чтобы удалить всю информацию с дисков на всех серверах, используемых компанией.
Возможный ущерб: последствия от этой бреши катастрофичны.
Хуже того, аналитик добавляет, что с технической точки зрения эту брешь использовать тривиально просто. Стало быть, возможность использования имеет критический уровень.
Пора нажимать аварийную кнопку, не так ли? Но предположим, что аналитик добавляет еще несколько слов. Использовать эту брешь может только тот, у кого есть ключ от серверной комнаты, потому что эта данная уязвимость требует физического доступа к компьютерам. Этот единственный ключевой показатель, простите за каламбур, радикально изменяет общую серьезность угрозы, порожденной данной конкретной брешью. Крайне низкая возможная доступность переводит стрелку на шкале серьезности с "тревога!" на "под контролем".
Наоборот, другая уязвимость может быть доступна любому начинающему хакеру в Интернете, но по-прежнему будет иметь незначительную серьезность, если возможный ущерб от этой бреши является несущественным.
Возможно, теперь более понятно, почему обманчива, если не совершенно безответственна, методика оценки безопасности по одному-единственному показателю, например, по количеству предупреждений об уязвимостях. В самом крайнем случае следует рассмотреть также указанные три фактора риска. Какая операционная система заслуживает больше доверия — с сотней брешей пренебрежимо малой серьезности или же с десятком брешей чрезвычайно высокой серьезности (использование бреши ведет к катастрофе)? Если при оценке не учитывать общую серьезность брешей, то подсчет их количества в лучшем случае не имеет никакого значения, в худшем — вводит в заблуждение.
исключение из правила
Показатель общей серьезности имеет три упомянутых "главных" компонента. Выше же было показано, как низкий возможный ущерб или низкая возможная доступность могут практически свести на нет другие факторы риска, какими бы высокими они ни были. Возможность использования — исключение из этого правила. Брешь, для использования которой требуется высококвалифицированный специалист, значительно меньше компенсирует высокий показатель возможного ущерба или возможной доступности.
Объясняется это просто. Если для использования бреши необходимо попасть в комнату с компьютерами, то дело не только в том, что это трудно, но и в том, что любая попытка проникнуть в эту комнату увеличивает для злоумышленника риск быть пойманным. И именно поэтому брешь, которую может использовать только сотрудник компании, менее серьезна, чем брешь, которую может использовать любой начинающий хакер из Интернета. В первом случае риск быть пойманным намного выше, чем во втором.
С другой стороны, анонимные злоумышленники-программисты весьма заурядной квалификации могут в течение нескольких недель или месяцев разрабатывать программу, позволяющую использовать какую-либо брешь в защите, практически не рискуя при этом быть пойманными. Единственная важная задача, стоящая перед таким злоумышленником, — активировать вредоносную программу так, чтобы невозможно было отследить ее автора.
Уже поверхностное знакомство с современным состоянием вредоносного программного обеспечения показывает самоочевидность этого исключения. Мало кто воспользуется базукой, чтобы проложить себе путь в машинный зал и "взломать" находящиеся там серверы. Но существует бесчисленное множество троянских программ, сетевых червей и вирусов, которые по-прежнему заражают множество компьютеров, и одна из причин в том, что программисты, талантливые и не очень, считают признаком профессионализма умение преодолеть технические трудности написания вредоносного кода или переработки вредоносного кода, написанного другими. Очевидно, что технические трудности необязательно компенсируют высокую опасность бреши, вызванную другими причинами.
применение показателя общей серьезности
Только оценив общую серьезность конкретной бреши, можно перейти к осмыслению таких показателей, как "сколько предупреждений об уязвимости существует для Windows по сравнению с Linux" или "сколько времени проходит между обнаружением и исправлением ошибки в случае Windows и в случае Linux".
Предположим, для одной операционной системы зарегистрировано намного больше предупреждений об уязвимостях, чем для другой. Этот показатель имеет смысл только в одном случае — если для данной системы имеется также больше предупреждений об уязвимостях с высоким уровнем общей серьезности. Одно дело, если довольно часто случаются разные мелкие неприятности, не представляющие практически никакой опасности, и совсем другое — когда регулярно обнаруживаются пусть и немногочисленные, но такие бреши, которые ставят под удар всю компанию.
Предположим, что для некоторой операционной системы зафиксировано более короткое время между обнаружением бреши и выходом соответствующей программной коррекции. И в этом случае показатель имеет смысл только тогда, когда это время относится к брешам с высокой общей серьезностью. Одно дело — несколько месяцев ждать коррекции для бреши, использование которой может нанести незначительный ущерб небольшому количеству компьютеров или даже совсем не причинить никакого вреда. И совсем другое дело — ожидать месяцами коррекции для бреши, использование которой может поставить под удар всю компанию.
Теперь перейдем непосредственно к способам оценки каждого из перечисленных показателей.
возможная доступность
Данный показатель учитывает меры, которые необходимо принять для получения доступа к компьютеру с целью использовать уязвимости в системе защиты. Обычно такие меры попадают в одну из перечисленных ниже категорий. На практике реальный порядок этих категорий может меняться, но приведенный список может оказаться удобным ориентиром. Кроме того, следует заметить, что существует несколько экзотических сложных случаев, которые в приведенном списке не рассматриваются. Например, закрытая программной коррекцией брешь в Windows Server 2003 сама по себе была не очень доступна, но она позволяла злоумышленнику сделать систему незащищенной перед серьезными угрозами. То есть это было одно из звеньев в цепочке уязвимостей. Категории в списке перечислены в порядке возрастания их серьезности.
1. Необходим физический доступ к компьютеру, но не требуется наличия действующей учетной записи пользователя.
2. Необходим физический доступ к компьютеру и требуется действующая учетная запись пользователя. /* Я бы, вообще-то поменяла пункты 1 и 2 местами, поскольку формальная логика подсказывает, что наличие двух обязательных условий в любом случае боллее труднодостижимая задача. Однако автор – барин, оставляем все как есть :) – прим. ред. */
3. Необходима действующая учетная запись пользователя, но не нужен физический доступ к атакуемому компьютеру. Достаточно доступа по локальной сети (из корпоративной сети компании).
4. Необходима действующая учетная запись пользователя, но не нужен физический доступ к атакуемому компьютеру. Атакуемый компьютер доступен через Интернет с удаленного компьютера.
5. Можно использовать брешь удаленно, через Интернет, не имея действующей учетной записи пользователя на атакуемом компьютере, но невозможно достичь бреши напрямую. Существует еще один барьер, например, маршрутизатор или межсетевой экран. Для этой категории трудно найти надлежащее место при перечислении по уровню серьезности, поскольку правильно сконфигурированный межсетевой экран может обеспечить стопро-центную защиту, но не всегда. Плохо сконфигурированный межсетевой экран может вообще не обеспечивать никакой защиты.
6. Можно использовать брешь удаленно, через Интернет, не имея действующей учетной записи пользователя на атакуемом компьютере, но невозможно достичь бреши напрямую. Существует еще один, более трудный для преодоления барьер. Этим барьером может быть другая программа (например, брешь существует в Microsoft SQL Server, но для ее использования необходимо внедрить элемент управления ActiveX или Javascript в веб-страницу, доступную через Microsoft Internet Information Server). В некоторых случаях для получения непрямого доступа необходимо вовлечь в этот процесс пользователя. Например, придется разослать по электронной почте сообщения, которые направят пользователей на web-страницу, содержащую вредоносный элемент управления или код. Широко используется способ, когда пользователю предлагается открыть файл, вложенный в электронное письмо. Серьезность этой категории меняется в зависимости от того, насколько искусно это вовлечение замаскировано под невинное действие.
7. Использовать брешь можно удаленно, через Интернет, не имея действующей учетной записи пользователя на атакуемом компьютере, но невозможно достичь бреши напрямую. Тем не менее, брешь используется косвенно, но автоматически. Например, брешь в операционной системе Windows используется немедленно и автоматически, как только пользователь открывает электронное письмо с помощью программы Outlook.
8. Использовать брешь можно удаленно, через Интернет, просто отправив через сеть информацию на атакуемый компьютер. Например, уязвимость типа "отказ в обслуживании" (DoS) можно использовать просто отправив специальные сетевые пакеты на атакуемый web-сайт, что сделает этот веб-сайт недоступным для других пользователей Интернета.
возможность использования
Этот показатель учитывает технические трудности, которые необходимо преодолеть, чтобы использовать брешь в защите. Обычно эти трудности попадают в одну из перечисленных ниже категорий. Категории перечислены в порядке возрастания их серьезности (на практике реальный порядок этих категорий может меняться, но приведенный список может оказаться удобным ориентиром).
1. Брешь существует, но еще не обнаружена. Для использования этой бреши необходимы либо исключительная компетентность, либо счастливый случай.
2. Для использования бреши необходимы высокая квалификация в программировании и глубокое знание операционной системы, но о существовании этой бреши известно недостаточно широко, из-за чего маловероятно, что ее используют многие нарушители.
3. О существовании бреши известно, и для ее использования необходимы высокая квалификация в программировании и глубокое понимание того, как функционируют атакуемые программное обеспечение и операционная система.
4. Для использования бреши необходима высокая квалификация в программировании, но уже создан вирус, троянская программа или сетевой червь, которые могут служить основой для атаки. Программисту требуется только модифицировать этот код, чтобы использовать новую брешь или сделать данный вирус более опасным.
5. Для создания кода, использующего брешь, необходима высокая квалификация в программировании, но подходящий код уже существует, и достаточно средней квалификации в программировании, чтобы усовершенствовать или модифицировать этот код так, что он будет использовать существующую брешь или "будущие" бреши.
6. Для использования бреши достаточно средней или начальной квалификации в программировании либо же элементарного знания компьютера. 7. Не имеет значения, насколько трудно использовать брешь, поскольку вся работа по созданию средств для использования этой бреши уже проделана, а вредоносный код сделан общедоступным для его применения новичками.
8. Кто угодно может использовать брешь, введя простой текст в командной строке или указав URL в веб-браузере.
возможный ущерб
Оценить этот показатель труднее всего. Требуется определить, по крайней мере, два различных набора категорий. Во-первых, надо учесть, какой вред причинит использование бреши приложениям или компьютерам. Во-вторых, необходимо оценить возможный ущерб с точки зрения последствий для всей компании. Например, в ситуации, когда брешь позволяет нарушителю прочитать неопубликованные веб-страницы. Вред от этого незначителен, если на компьютере не хранится конфиденциальная информация. Но если неопубликованная веб-страница содержит какую-либо конфиденциальную информацию, например, номера кредитных карт, то общий возможный ущерб может быть очень большим, и это при том, что возможный технический ущерб минимален. Ниже приводятся (в порядке возрастания серьезности) наиболее важные факторы, которые следует учитывать при оценке возможного технического ущерба в результате использования какой-либо конкретной бреши.
1. Брешь влияет только на производительность другого компьютера, но не настолько, чтобы он перестал отвечать на запросы.
2. Брешь влияет только на собственные программы или файлы нарушителя, но не затрагивает файлы или программы других пользователей.
3. Брешь делает незащищенной информацию в файлах других пользователей, но не учетную запись администратора или системные файлы.
4. Брешь позволяет нарушителю просматривать, изменять или удалять пользовательские файлы. Она не дает возможности просматривать, изменять или удалять файлы администратора или системные файлы.
5. Брешь позволяет нарушителю просматривать критичную информацию либо путем исследования сетевого трафика, либо путем доступа с правами "только чтение" к файлам администратора или к системным файлам.
6. Брешь позволяет нарушителю получить некоторые, но не все, полномочия административного уровня, возможно, в ограниченном окружении.
7. Брешь позволяет нарушителю вызвать отказ системы или каким-то иным путем заставить ее не отвечать на обычные запросы. Это — типичная атака "отказ в обслуживании". Однако нарушитель фактически не может получить контроль над компьютером, за исключением того, что компьютер перестанет отвечать на запросы.
8. Брешь позволяет нарушителю изменить или удалить все привилегированные файлы и информацию. Нарушитель может получить полный контроль над атакуемой системой и фактически причинить такой же ущерб, какой способен нанести полностью авторизованный системный администратор.
уровень общей серьезности
С учетом описанных выше трех факторов общая серьезность угроз может изменяться от минимальной до катастрофической. Рассмотреть все перестановки не представляется возможным, но несколько примеров могут оказаться полезными. Эти примеры основываются на категориях возможного ущерба в сочетании с различными категориями возможной доступности и возможности использования.
1. Если анонимный злоумышленник из Интернета сумеет снизить производительность компьютеров компании, то оценка последствий может варьироваться от "мелкая неприятность" до "разрушительный удар по финансам" в зависимости от того, насколько критичной является производительность системы для деятельности компании.
2. Атака на собственную учетную запись является бессмысленной, но такая саморазрушительная деятельность может создать для ИТ-подразделения лишнюю работу по восстановлению.
3. Потенциальная серьезность бреши, позволяющей просматривать только файлы работающего в том же здании сослуживца, минимальна, даже если эту брешь тривиально просто использовать. Уровень серьезности возрастает, когда файлы этого сослуживца содержат конфиденциальную информацию, и уменьшается, если велика вероятность поимки нарушителя. С другой стороны, если просматривать конфиденциальные файлы в сети компании может любой злоумышленник из Интернета (высокая возможная доступность), общая серьезность бреши резко возрастает.
4. Если брешь позволяет нарушителю изменять или удалять файлы работающего в том же здании сослуживца, серьезность этой бреши тем меньше, чем регулярнее выполняется в компании резервное копирование и чем больше вероятность поимки нарушителя. Если нарушитель может изменять файлы учетной записи пользователя на удаленном компьютере, то серьезность меняется в зависимости от важности этой учетной записи и предоставляемого ею сервиса. Например, серьезность может варьироваться от незначительного искажения веб-страниц до их полного удаления.
дисбаланс приложений
В дебатах о превосходстве одной операционной системы над другой часто упускается из виду, что уязвимости в системе защиты почти всегда коренятся в приложениях. Данное обстоятельство создает определенные трудности при сравнении Windows и Linux, потому что эти две системы находятся в неравном положении с точки зрения переносимости и доступности приложений.
С одной стороны, большинство популярных приложений для Microsoft Windows составляют приложения Microsoft, и они запускаются только под Windows. Когда обнаруживается брешь в Microsoft Exchange, можно обоснованно полагать, что эта проблема затронет только клиентов Windows. Microsoft Exchange не функционирует ни в Linux, ни в Solaris, ни где-либо еще, кроме Windows.
С другой стороны, веб-сервер Apache чаще всего ассоциируется с Linux или другими *NIX-системами, но Apache функционирует и под управлением Windows. Поэтому, сравнивая общую безопасность Windows и Linux, можно ли считать, что брешь в Apache — это дефект только Linux? Или она негативно сказывается и на Linux, и на Windows?
Еще больше усложняет проблему то, что известно несколько случаев, когда брешь в Apache почти (или даже совсем) не опасна для Linux, но является серьезной уязвимостью в Windows. Обратная ситуация встречается крайне редко, если вообще встречается. /* Применительно к Apache точно не скажу, хотя мне кажется, такая ситуация может иметь место. Но с другими кросс-платформенными продуктами сплошь и рядом бывает, что уязвимость может проявиться только под *NIX-системами. – прим. ред. */ Следует ли понижать оценку общей безопасности Windows потому, что эта система более подвержена неблагоприятному воздействию, чем Linux, при использовании программного обеспечения, которое обычно ассоциируется с Linux? Вопрос о том, учтен ли какой-либо из этих факторов при сравнении общей безопасности Windows и Linux, ни в коем случае нельзя оставлять без внимания.
настройка и администрирование
Наконец, различие в подходе к настройке и администрированию серверов в Linux и в Windows, как уже отмечалось, возможно, является самым важным различием между этими двумя операционными системами.
Windows предлагает использовать знакомый интерфейс, что означает администрирование ОС Windows Server 2003 на самом сервере. Linux не полагается на локальное использование графического интерфейса и не поощряет этого отчасти потому, что функционирование графической среды на сервере — это необоснованная трата ресурсов, а отчасти потому, что от этого возрастают угрозы безопасности сервера. Так, любой сервер, предлагающий использовать графический интерфейс на компьютере сервера, предлагает также выполнять на сервере похожие операции, например, использовать веб- навигатор. В результате сервер подвергается угрозам, порожденным уязвимостями в защите браузера. Любой сервер, побуждающий пользователя к удаленному администрированию, защищен от подобных угроз. Если администрирование сервера Linux осуществляется удаленно, через учетную запись пользователя на рабочей станции, то брешь в браузере создает угрозу только этой удаленной рабочей станции, а не серверу. Именно поэтому брешь в защите браузера потенциально опаснее для Windows Server 2003, чем для Red Hat Enterprise Server AS.
В следующей, заключительной, части статьи будут представлены списки реальных уязвимостей под обе осбуждаемые платформы с оценкой серьезности каждой уязвимости, ну и, конечно, будут сделаны какие-то выводы.
продолжение следует.
Николас Петрели (Nicholas Petreley), аналитик по Linux в исследовательской компании Evans Data Corporation, обозреватель "ComputerWorld", "LinuxWorld".
Сетевые решения. Статья была опубликована в номере 12 за 2005 год в рубрике save ass…
