id: Гость   вход   регистрация
текущее время 09:11 28/03/2017
создать
просмотр
редакции
ссылки

Компьютер как неприступная крепость


Оглавление документа:

Концепция эшелонированной обороны


Успешная организация эшелонированной (=многоуровневой) обороны подразумевает проведение анализа угроз, в ходе которого определяются:

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

Далее для каждого вектора угрозы предусматривается несколько уровней (способов) защиты.

Ресурсы и их значение


  • Структура файловой системы:
    • /bin, /usr/bin (Исполняемые файлы)
    • /sbin, /usr/sbin (Исполняемые файлы, запускаемые только суперпользователем)
    • /etc (Конфигурационные данные)
    • /tmp (Каталог для хранения временных файлов)
    • /var (Изменяемые данные, используемые сервисами и демонами)
    • /home (Пользовательские данные, личные файлы пользователей)
    • /lib, /usr/lib (Библиотеки, используемые программами)
    • /proc, /sys (Специальные ФС)
    • /boot, /lib/modules, /dev/kmem (Данные ядра и модули)
    • /dev (Файлы устройств)
    • Другое:

Опасности, которым могут подвергнуться ресурсы


  • Данные, критичные для правильной работы системы:
    • Исполняемые файлы: могут быть заменены, инфицированы или уничтожены.
    • Динамические библиотеки: также содержат выполняемый код и могут быть инфицированы, уничтожены и т.д. Многие программы загружают одни и те же библиотеки, поэтому получение контроля над одной библиотекой может дать контроль над несколькими программами.
    • Конфигурационные файлы: Контролируют поведение программ. Также могут содержать чувствительную информацию. Доступ для чтения должны иметь только ассоциированные программы.
    • Объекты ядра: Код ядра и загружаемые модули находятся на диске в виде файлов. Их модификация может предоставить злоумышленнику полный и абсолютный контроль над системой.
    • Файлы устройств: прямой доступ к носителям информации обходит контроль доступа к отдельным объектам ФС, чего допускать не следует.
    • Аутентифицикационная информация: Данные, используемые для аутентификации, есть самый критичный элемент всей системы контроля доступа. Должны быть защищены от всех попыток доступа, не являющихся абсолютно необходимыми.
  • Менее критичные данные:
    • Сетевые ресурсы: Удаленные сервера и локальные сокеты.
    • Файлы логов:
    • Другие объекты:

Векторы угрозы


  • Проникновение извне:
    • Эксплуатация удаленной уязвимости в демоне или ядре
    • Эксплуатация локальной уязвимости в демоне или ядре
    • Взлом системы методом грубой силы (bruteforce)
    • Инфицирование вирусами, червями, троянскими конями
  • Внутренние угрозы:
    • Получение пользователем данных, для него не предназначенных, в случае неверной установки прав доступа
    • Действия инсайдера
    • Злоупотребление полномочиями администратора системы
    • Ошибка администратора системы

Эшелоны защиты


Соответственно, средства защиты против удаленного атакующего можно разместить на трех этапах:

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

Третий пункт выполняется с помощью средств типа Tripwire, AIDE и др.


Первые два пункта выполняются стандартными средствами Linux или же посредством систем принудительного контроля доступа.

Средства принудительного контроля доступа


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


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


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


Для ОС GNU/Linux в наличии имеются следующие системы:


RSBAC или SELinux


  • RSBAC уникален. Уникален тем, что это фреймворк, который предоставляет возможность подключения модулей, реализующих любые модели контроля доступа, в любой комбинации. Все модули работают независимо друг от друга, а решение о разрешении или запрете доступа принимается на основании решений всех работающих в данный момент модулей. SELinux, напротив, система монолитная. Модульными могут быть только политики.
  • Как следствие предыдущего пункта, RSBAC намного более прост в освоении и настройке, не уступая при этом SELinux в возможностях. Настройка же SELinux занятие не для слабонервных по причине исключительной сложности. А сложность, как мы знаем, враг безопасности.
  • SELinux для работы нужна файловая система, поддерживающая т.н. "расширенные атрибуты". RSBAC не зависит от файловой системы.
  • RSBAC предоставляет возможность наследования различных атрибутов файлами и процессами. В SELinux все атрибуты должны указываться явно.

С другой стороны:


  • RSBAC не включен в основную ветку ядра, и, как следствие, менее активно разрабатывается и отлаживается.
  • RSBAC представляет приоритет безопасности над скоростью

Стандартные модули RSBAC


Название модуля Кодовое имя Краткое описание
Authenticated User AUTH Аутентификация пользователей
User Management UM Управление пользователями в пространстве ядра
Role Compatibility RC Ролевая модель контроля доступа
Access Control Lists ACL Подробнейшие списки контроля доступа
Mandatory Access Control MAC Многоуровневый контроль доступа
Pageexec PAX Предотвращение выполнения нежелательного кода
Dazuko DAZ Сканирование на вирусы при доступе к файлам
Linux Capability CAP Контроль Linux Capabilities
Jail JAIL Инкапсуляция отдельных процессов
Linux Resources RES Контроль системных ресурсов
File Flags FF Установка спецфлагов контроля доступа на файлы и каталоги
Privacy Model PM Защита конфиденциальной информации

Модуль FF


* Атрибут Разрешены вызовы
128 FF_add_inherited * (наследование ограничений)
1 FF_read_only CHDIR, EXECUTE, READ, READ_OPEN
2 FF_execute_only CHDIR, CREATE, EXECUTE
4 FF_search_only кроме CHDIR, CREATE, READ, READ_OPEN, WRITE
8 FF_write_only кроме EXECUTE, READ*, MOUNT, UMOUNT
16 FF_secure_delete * (безопасное удаление файлов)
32 FF_no_execute кроме EXECUTE
64 FF_no_delete_or_rename кроме DELETE и RENAME
256 FF_append_only APPEND_OPEN, CHDIR, CREATE, LINK_HARD, READ, READ_OPEN, WRITE
512 FF_no_mount кроме MOUNT и UMOUNT

Модуль JAIL


Модуль JAIL предоставляет новый вызов rsbac_jail, который вызывает chroot (chroot("/")) и налагает дополнительные ограничения на вызвавший процесс и все его подпроцессы.


Процессы в jail не могут:


  • Загружать или выгружать модули ядра
  • Выключать или перезагружать систему
  • Монтировать или размонтировать ФС
  • Создавать сокеты кроме как типов UNIX и INET (IPv4).
  • Использовать INET (IPv4) адреса кроме заданного (optionally, the ANY address 0.0.0.0 can be silently changed to the given address).
  • Создавать raw INET сокеты.
  • Обращаться к IPC объектам вне jail.
  • Создавать файлы устройств.
  • Посылать сигналы, трассировать или получать статус процессов вне jail.
  • Изменять DAC-атрибуты с включением suid или sgid флагов.
  • Устанавливать лимиты ресурсов (rlimits).
  • Изменять параметры не-rlimit SCD или NETDEV.
  • Получать доступ к атрибутам RSBAC.
  • Получать доступ к сетевым шаблонам RSBAC.
  • Выключать DAC.
  • Включать или выключать модули RSBAC и нефорсированный режим (softmode).
  • Получать доступ к другим пространствам имён (если включена опция).

Некоторые из этих ограничений могут быть выключены, см. опции обёртки rsbac_jail.


Дополнительно, rsbac_jail позволяет также ограничить IP-адрес, на котором разрешено слушать процессу.

Модуль RC

Модуль ACL

Модуль MAC

Модуль PAX


Типы уязвимостей


В соответствии с классификацией CWE (Common Weakness Enumeration) различают следующие типы уязвимостей:

Type Description
auth Weak/bad authentication problem
buf Buffer overflow
CF General configuration problem, not perm or default
crlf CRLF injection
crypt Cryptographic error (poor design or implementation), including plaintext storage/transmission of sensitive information.
CSRF Cross-Site Request Forgery (CSRF)
default Insecure default configuration, e.g., passwords or permissions
design Design problem, generally in protocols or programming languages. Since 2005, its use has been limited due to the highly general nature of this type.
dos-flood DoS caused by flooding with a large number of legitimately formatted requests/etc.; normally DoS is a crash, or spending a lot more time on a task than it 'should'
dos-malform DoS caused by malformed input
dos-release DoS because system does not properly release resources
dot Directory traversal (file access via '..' or variants)
double-free Double-free vulnerability
eval-inject Eval injection
form-field CGI program inherently trusts form field that should not be modified (i.e., should be stored locally)
format-string Format string vulnerability; user can inject format specifiers during string processing.
infoleak Information leak by a product, which is not the result of another vulnerability; typically by design or by producing different 'answers' that suggest the state; often related to configuration / permissions or error reporting/handling.
int-overflow A numeric value can be incremented to the point where it overflows and begins at the minimum value, with security implications. Overlaps signedness errors.
link Symbolic link following
memleak Memory leak (doesn't free memory when it should); use this instead of dos-release
metachar Unescaped shell metacharacters or other unquoted 'special' char's; currently includes SQL injection but not XSS.
msdos-device Problem due to file names with MS-DOS device names.
not-specified The CVE analyst has not assigned a flaw type to the issue, typically similar to 'other'.
other Other vulnerability; issue could not be described with an available type at the time of analysis.
pass Default or hard-coded password
perm Assigns bad permissions, improperly calculates permissions, or improperly checks permissions
php-include PHP remote file inclusion
priv Bad privilege assignment, or privileged process/action is unprotected/unauthenticated.
race General race condition (NOT SYMBOLIC LINK FOLLOWING (link)!)
rand Generation of insufficiently random numbers, typically by using easily guessable sources of 'random' data
relpath Untrusted search path vulnerability – Relies on search paths to find other executable programs or files, opening up to Trojan horse attacks, e.g., PATH environment variable in Unix.
sandbox Java/etc. sandbox escape – NOT BY DOT-DOT!
signedness Signedness error; a numeric value in one format/representation is improperly handled when it is used as if it were another format/representation. Overlaps integer overflows and array index errors.
spoof Product is vulnerable to spoofing attacks, generally by not properly verifying authenticity.
sql-inject SQL injection vulnerability
type-check Product incorrectly identifies the type of an input parameter or file, then dispatches the wrong 'executable' (possibly itself) to process the input, or otherwise misrepresents the input in a security-critical way.
undiag Undiagnosed vulnerability; report contains enough details so that the type could be determined by additional in-depth research, such as an un-commented exploit, or diffs in an open source product.
unk Unknown vulnerability; report is too vague to determine type of issue.
upload Product does not restrict the extensions for files that can be uploaded to the web server, leading to code execution if executable extensions are used in filenames, such as .asp, .php, and .shtml.
webroot Storage of sensitive data under web document root with insufficient access control.
XSS Cross-site scripting (aka XSS)

Первые три места по распространённости занимают уязвимости типа XSS (Межсайтовый скриптинг), buf (Переполнение буфера) и sql-inject (SQL-инъекция).

Настройка RSBAC: конкретные примеры


Ссылки



 
Комментариев нет [показать комментарии/форму]
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3