Введение

Эта работа является ответом на распространенный недавно доклад о взломе веб-сервера Apache.com Хардбитом и {}. Изложенное в докладе не содержит каких-либо уязвимостей, но оно может служить отличным примером взлома веб-сервера. Что в свою очередь является прекрасной возможностью продемонстрировать как Доверяемая Операционная Система (TOS) может быть использована для предотвращения этой атаки без изменения ошибочных настроек в системе. Необходимо отметить, что данный документ рассматривает только вышеуказанную атаку, а также что TOS могут быть использованы и против более прямых способов атак (переполнение буферов и т.д.).

Атака

Проблема: Внедрение Скриптов. Первой фазой атаки был поиск способов внедрения скриптов на веб-сервер. Атакующие достигли цели путем обнаружения отображений со страниц веб-сервера в директории ftp сервера, доступные всем для записи. Затем атакующие создали скрипт на языке PHP, позволяющий исполнить любую команду в системе.

Решение: Изоляция Приложения и Сетевая Безопасность. В данном случае это просто вопрос настройки веб-сервера, которая позволяла создавать страницы веб-сервера анонимному пользователю ftp. Ошибки в настройках такого типа не являются чем-то необычным, а составляют часть более общей проблемы обеспечения безопасности веб-серверов. Этот класс проблем составляет возможность внедрения нового или изменения старого содержимого сервера. Сперва необходимо получить доступ к системе от лица пользователя, имеющего возможность создавать содержимое веб-сервера. Это было проделано во время взлома сервера Apache от лица анонимного пользователя ftp. Другие методы состоят в атаке самого веб-сервера с целью получения полномочий привелигированного пользователя (root), дающих возможность модификации любого файла в системе. Обычно это не так уж и сложно для терпиливого атакующего ("хакера"), как показывает взлом сервера Apache.

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

Обычно набор иерархических компонентов (классификация) включает в себя следующее:

• Сов.Секретно
• Секретно
• Конфиденциально(ДСП)
• Несекретно
• Низший системный уровень (System Low)

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

Примерами неиерархических категорий могут быть:

• Веб_Сервер
• Внутренний
• Внешний
• Содержимое_Веб
• Скрипты_Веб
• Публичный_ФТП
• SQL

Принцип действия неиерархических категорий отличается от принципа действия классификаций. Метка безопасности может содержать более одной категории. Говорят, что один набор категорий доминирует над другим, если он включает в себя все категории другого набора. Например, процесс имеющий набор Веб_Сервер и Содержимое_Веб сможет читать файлы, которые имеют только категории Веб_Сервер или Содержимое_Веб. Для того, чтобы записать в файл (на самом деле необходим доступ и на чтение и на запись), процесс должен иметь такой-же набор категорий как и у файла. Рассмотренный выше процесс с набором категорий Веб_Сервер/Содержимое_Веб сможет осуществить запись только в файлы с набором категорий Веб_Сервер/Содержимое_Веб (и больше никаких других категорий).

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

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

Для защиты содержимого веб страниц от атак, администратор узла просто помечает веб сервер меткой, например, "Конфиденциально/Веб_Сервер,Содержимое_Веб,Внешний". Содержимое узла веб помечается как "Несекретно/Содержимое_Веб". Это позволяет веб серверу читать и исполнять веб скрипты, но запрещает их модифицировать. Сетевые правила установлены таким образом, что все соединения с веб сервером будут помечены как "Конфиденциально/Веб_Сервер,Содержимое_Веб", получая возможность взаимодействия с веб сервером. Любая удачная атака на веб сервер приведет к разрешению доступа на модификация файлов с меткой "Конфиденциально/Веб_Сервер,Содержимое_Веб,Внешний", что не позволит изменять содержимое веб страниц, а также и других файлов в системе (ведь никто не устанавливал эту метку). По существу атакующий получит доступ к системе, но не возможность что либо изменять в ней.

Сервер ftp в этой системе должен исполняться с меткой "Конфиденциально/Публичный_ФТП,Внешний". Сетевые правила для сервера должны быть установлены таким образом, чтобы всем соединениям с ним присваивалась данная метка. Тогда даже если веб сервер будет иметь настройки путей на каталоги ftp сервера, то содержимое этих каталогов будет ему недоступно, соответственно он не сможет запустить какой-либо скрипт оттуда.

Проблема: Терминальный Доступ. Следующая фаза атаки состояла во внедрении в систему доступной удаленно командной оболочки. Они называются bindshells, т.к. используют системный вызов bind для подсоединения к сети. После внедрения атакующий может просто использовать telnet для подсоединения к сетевому порту, который слушает bindshell, установленный в системе, и получить доступ к системе на том же уровне, что и bindshell.

Решение: Изоляция Приложений. В продолжение обсуждения TOS, давайте представим, что администратор не выделил ftp сервер в отдельную категорию, но оставил его файлы доступными на чтение веб серверу. Мы также можем предположить, что атакующий мог найти "дырку" во вспомогательной CGI программе и получил возможность внедрить программу в систему. Раз bindshell был внедрен в систему, он сможет исполняться только с меткой, эквивалентной метке веб сервера. Это означает, что bindshell будет исполняться как пользователь "nobody" с меткой "Конфиденциально/Веб_Сервер,Содержимое_Веб,Внешний". Так как в системе больше нет файлов с такой меткой, пользователь (атакующий) не сможет изменить какой-либо файл в системе. Не существует пути обойти эту метку. Ниже я поясню почему.

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

Решение: Сетевые Метки Безопасности и Защищенный CGI Back-End. Для решения этой проблемы на придется слегка изменить архитектуру системы. Наша версия TOS, известная как PitBull, предоставляет расширения для веб серверов Apache и Netscape Enterprise Server, которое позволяет исполнять CGI-скрипты в их собственных изолированных друг от друга средах(областях памяти?). Задействуя данную возможность, администратор заставить CGI-скрипты исполняться в полностью изолированных compartments, оберегая тем самым систему от любых взломов. В обсуждаемых системах эти CGI-скрипты будут исполняться с меткой "Конфиденциально/Скрипты_Веб". Даже если взом произошел и bindshell был внедрен в систему, атакующий не сможет даже установить с ним соединение. Другими словами, любая атака не приведет к появлению возможности дополнительных сетевых соединений. Причина этого состоит в том, что CGI-скрипты не содержат доступа к неирархической категории "Внешний", которая необходима для установления сетевых соединений с общедоступной сетью через сетевой интерфейс. К тому же, атакующий не сможет установить сетевой редиректор(?) на приложение MySQL в силу описанных выше сетевых ограничений. Но все же давайте предположим, что атакующий все же получил доступ к серверу MySQL. Сервер MySQL исполняется со своей собственной меткой безопасности "Конфиденциально/SQL", изолирующей его от всех остальных. Все файлы в системе должны иметь "Низший Системный Уровень". Это означает, что сервер MySQL не сможет изменить ни одного файла за исключением своих собственных.

Почему атакующий не может обойти свою метку?

Самые недоверчивые из вас уже задаются вопросом - не может ли атакующий просто найти способ обойти свою метку, или стать root'от, или еще каким специальным пользователем? Ответ - конечно, нет. Причина состоит в том, что TOS реализуют концепцию минимальных привелегий. Концепция минимальных привелегий отбрасывает root'а как привелигированного пользователя, в место этого в ней реализована система привелегий, дающая права приложениям основываясь исключительно на функциях, необходимых для работы конкретного приложения. Например, если приложению необходимо подключение к сети (например, веб серверу), ему просто присваивается привелегия "подключение к сети". В стандартной ОС приложение должно будет исполняться с привелегиями привелигированного пользователя, получая таким образом полный доступ к системе. В TOS оно получит только возможность подключения к сети и все. Ни тебе полного доступа к файлам, ни использование прав любого пользователя и т.д. Администраторы могут исполнять административные команды (которые имеют привелегии, позволяющие им обходить систему защиты). Эти команды с легкостью изолируются от нападающего помещением их в уровень "Сов.Секретно/Внутренний". Таким образом единственным способом получить эту метку является регистрация в системе администратором с "Внутреннего" соединения(терминала?). Напрмер, существует модифицированная версия Secure Shell Server (sshd), которая позволяет администраторам регистрироваться в системе и осуществлять административное управление функциями безопасности.

Подведем итоги

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

Кто производит такие системы?

В настоящее время существуют два основных коммерческих производителя доверяемых систем. Argus Systems Group, Inc. производит PitBull .comPack suite для Solaris 7, готовятся версии для Solaris 8, AIX, UnixWare и Linux для 32-х и 64-х битных архитектур. HewlettPackard разрабатывает(?) TOS, известную как VVOS (Virtual Vault OS), которая функционирует на аппаратном обеспечении HP.

Также существуют два OpenSource проекта по разработке Доверяемых Операционных Систем. TrustedBSD разрабатывается на основе ОС FreeBSD. Информацию об этом проекте вы можете найти по ссылке TrustedBSD Project. SGI открыла часть кода, который может использоваться в качестве примера построения TOS. Его можно посмотреть на Sample B1 implemetation.

Получите бесплатно

Argus Systems Group, Inc. выступило с инициативой, известной как Революция Argus, в рамках которой бесплатно доступен PitBull, базовая TOS класса B1 (по "Оранжевой" книге), для индивидуального некоммерческого использования. Информацию об этой инициативе можно получить по ссылке Argus Revolution.

Координаты для связи

От переводчика

Перевод статьи размечен в DocBook V3.1. Любые замечания, предложения, дополнения, исправления приветствуются по адресу Ilmar S. Habibulin. Оригинал статьи в простом тексте можно взять здесь. Оригинал перевода в sgml соответственно здесь. Кодировка koi8-r.

Да, вот еще что. Я не совсем согласен с автором в разделе "Кто производит такие системы?". Я считаю, что в нем можно было бы упомянуть тот же Trusted IRIX 6.4.

обсудить  |  все отзывы (0)
Выберите оценку 10 (изумительно) 9 (отлично) 8 (хорошо) 7 (неплохо) 6 (средненько) 5 (сойдет) 4 (так себе) 3 (слабо) 2 (плохо) 1 (отвратительно) Вернуться в раздел Перейти к рейтингу Перейти к обсуждению Вернуться к статье	[24374; 6; 5.83]