Дельта синхронизация без облака

Ранее мы показывали разные способы синхронизации криптодиска между ПК и Android-устройством.

Дельта-синхронизация крипто-дисков

Существуют разные способы зашифровать "облако". Один из них - поместить в облако крипто-диск. В предыдущей статье мы писали, почему это не всегда удобно.

Смотрим плавность хода с помощью BMW Rheingold

Всем знакома ситуация, когда двигатель немного "троит", но пропусков зажигания нет...

Облачный хостинг VDS за 2 минуты

Настоящий облачный VDS-хостинг от UltraVDS: тестируем производительность

LIDS: система обнаружения и защиты от вторжения


Денис Колисниченко

В этой статье мы поговорим о довольно популярной системе - LIDS (Linux Intrusion Detection System). Первоначально LIDS была простой системой обнаружения вторжения, но с годами процесс развивался и превратился в комплексную систему обеспечения безопасности Linux-машины. Сейчас LIDS "доросла" до уровня Grsecurity и в кое в чем даже превосходит ее. Преимуществом второй версии LIDS является поддержка LSM (загружаемых модулей безопасности), в предыдущих версиях такой поддержки не было, что усложняло установку систему и работу с ней.

Примечание. Модули защиты (LSM) - это сравнительно молодое средство управления доступом. Все началось с разработки различных систем управления доступом. Все они реализовывались в виде патчей ядра Linux. Но из-за отсутствия централизованной координации в результате получилось, что у каждого проекта защиты был свой патч для ядра, часто несовместимый с другими патчами. В прошлом Линус Торвальдс категорически отвергал все эти патчи, но в 2001 году в ответ на технологию SELinux, представленную NSA (агентство национальной безопасности) на Саммите Ядра Линукс (Linux Kernel Summit), он отметил, что для включения в ядро он будет рассматривать более обширную систему безопасности. Так появился проект LSM (Linux Security Modules). Цель LSM - предоставить разработчикам систем защиты общий (единый) интерфейс для реализации проектов, основанных на ядре. Реализация такой системы позволит меньше зависеть от ядра, и не будет требовать его перекомпиляции, как в случае с патчами. Все LSM-модули используют стандартный интерфейс для взаимодействия с ядром, который не будет изменять с выходом следующего релиза (не версии) ядра.

Установка

LIDS реализован как патч ядра и набор пользовательских утилит, загрузить все это можео с сайта http://www.lids.org/download.html. В отличие от других проектов, патчи которых подходят только к определенной версии ядра, патчи LIDS подходят для всех версий ядра 2.4.x и 2.6.x, поэтому LIDS будет работать с любым ядром.

Конфигурирование ядра

Распакуйте архив с LIDS, перейдите в каталог ядра и примените патч:

# cd /usr/src
# wget http://www.lids.org/download/v2.6/2.6.7/lids-2.2.0rc3-2.6.7.tar.gz
# tar -zxvf lids-2.2.0rc3-2.6.7.tar.gz
# cd linux-2.6.7
# patch -p1 < /usr/src/lids-2.2.0rc3-2.6.7/lids-2.2.0rc3-2.6.7.patch

После этого можно приступить к конфигурированию ядра. LIDS требует включить поддержку алгоритма SHA256, опцию для включения этого алгоритма можно найти в меню Cryptography Options/Cryptography API. Опции конфигурации LIDS вы найдете в меню Security Options. Желательно выключить SELinux и Capabilities.

Рассмотрим опции LIDS:

Attempt Not to Flood Logs (CONFIG_LIDS_NO_LOOD_LOG): ограничивает частоту протоколирования идентичных сообщений

Allow Switching the LFS and States (CONFIG_LIDS_ALLOW_SWITCH): LFS (LIDS-free session, о ней мы поговорим чуть позже) позволяет администратору выполнять команды без всяких ограничений со стороны LIDS. Это довольно полезно, но может быть источником для атаки вашей системы. Я рекомендую включить эту опцию на первые несколько дней - пока вы экспериментируете с LIDS, а потом, когда все будет настроено - выключить ее.

Allow Switch Off the Linux Free Session (CONFIG_LIDS_ALLOW_LFS): позволяет выключить LIDS во время выполнения системы. Безопаснее, когда эта опция выключена.

Restrict Mode Switching to Special Terminals (CONFIG_ LIDS_RESTRICT_MODE_SWITCH): позволяет задать терминалы, с которых разрешается LFS. Можно выбрать три класса терминалов: консоль (console), последовательная консоль (serial console) и PTY. Третий наиболее опасный, поскольку он позволяет злоумышленнику удаленно запустить LFS. Выберите только первый класс, позволяющий запускать LFS только пользователям, физически работающим с машиной.

Lidstools

После компиляции ядра можно установить пакет lidstools. Сценарию ./configure нужно явно передать каталог ядра:

$ tar -zvxf lidstools-2.2.5
$ cd lidstools-2.2.5rc1.tar.gz
$ ./configure KERNEL_DIR=/usr/src/linux-2.6.7
$ make
$ su
# make install

При установке программы (make install) вас попросят ввести пароль для администрирования LIDS: он не должен совпадать с паролем root!

Чтобы использовать новое ядро, вам нужно перезагрузить систему. Если вам нужно отключить LIDS, перед загрузкой системы передайте ядру параметры security=0.

Администрирование LIDS

Поскольку мы уже рассмотрели конфигурирование ядра, теперь займемся конфигурирование пользовательского уровня. Как и Grsecurity, LIDS позволяет управлять, как файлы и процессы будут взаимодействовать в системе. Кроме этого LIDS предоставляет две очень полезные функции: LFS и "опечатывание" ядра

"Опечатывание" ядра (sealing the kernel)

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

LIDS предлагает концепцию "опечатывания" ядра. Когда ядро "опечатано" никто не может загрузить или выгрузить модуль. Опечатать ядро можно с помощью команды lidsadm -I. Данную команду нужно поместить в сценарии загрузки системы, только при этом убедитесь, что ДО команды lidsadm -I все необходимые модули загружены. "Опечатывание" ядра также предусматривает ограничения набора возможностей, но об этом мы поговорим чуть позже.

LFS (LIDS-free Sessions) - сессии без LIDS

LFS - это всего лишь оболочка, на выполнение команд которой не накладываются ограничения LIDS. Это позволяет администратору работать в системе как обычно, без выключения основной системы безопасности - ведь если система LIDS включена, то ограничения накладываются даже на пользователя root. Однако LFS потенциально опасна: ведь если злоумышленнику удастся получить доступ к LFS, то он получит полный контроль над системой - вплоть до отключения LIDS. Доступ к LFS контролируется установленным ранее паролем. Дополнительно, при конфигурации ядра можно указать терминалы, с которых разрешается доступ к LFS (очень хорошее решение).

Главное назначения LFS - это разрешение администратору редактировать файлы в каталоге /etc/lids, который недоступен во время работы LIDS даже пользователю root. В этом каталоге находятся следующие файлы:

  • lids.cap: ограниченный набор возможностей
  • lids.conf: ACL (будет рассмотрен позже)
  • lids.pw: пароль администратора LIDS
  • lids.ini: начальные конфигурационные значения

Lidsadm

Администрирование LIDS выполняется программой lidsadm. Рассмотрим опции программы:

  • -P: зашифровывает пароль LIDS, например, lidsadm -P mypassword
  • -S: изменить аспект защиты LIDS
  • -I: "опечатать" ядро. Для этой опции не нужен пароль
  • -V: просмотр состояния системы
  • -h: вывести краткую справку
  • -v: вывести версию lidsadm

Опция -S используется вместе с одним из следующих флагов, предваренным знаком + (включить) или знаком (-) выключить:

LIDS_GLOBAL: включить/выключить LIDS глобально

RELOAD_CONF: перезагрузить файл lids.conf и обновить список защищенных инодов (об этом мы поговорим чуть позже)

LIDS: включить/выключить LIDS локально, то есть создать LFS. LFS будет применена только к текущей оболочке

ACL_DISCOVERY: используется для отладки; когда включена, нарушения правил не запрещаются SHUTDOWN: переключается в состояние shutwodn

Например, чтобы войти в LFS, выполните команду:

# lidsadm -S - -LIDS

Чтобы выключить защиту LIDS:

# lidsadm -S - -LIDS_GLOBAL

ACL файлов и возможностей

ACL используется для управления доступом к различным объектам, например, к файлам или ресурсам (но в отличие от Grsecurity, в LIDS нет ролей). В LIDS есть два типа ACL: ACL файлов (контролирует доступ к файлам и каталогам) и ACL возможностей (регулирует возможности исполнимых файлов).

ACL файлов

LIDS определяет четыре режима для объектов:

DENY: доступ к файлу запрещен. При обращении приложения (например, ls или cat) к этому файлу, оно получит сообщение об ошибке No such file or directory (ENOET) - нет такого файла или каталога. Внешне будет выглядеть так, как будто файл не существует.

READ: объект может быть открыт только в режиме "только чтение", запись запрещена

APPEND: объект может быть открыт для чтения или для добавления информации. Данный режим удобно использовать для файлов журналов.

WRITE: чтение и запись не ограничивается. LIDS не защищает этот файл.

Данные режимы могут быть заданы для файла и для каталога. Если режим применяется для каталога, то он будет примерен ко всем файлам этого каталога.

В LIDS ACL описывается так:

<Тип ACL> <субъект> <объект> <доступ> <наследование>

Тип ACL определяет, на какой стадии работы системы будет контролироваться доступ к системе. Доступно четыре типа:

  • BOOT - доступ будет контролироваться на стадии загрузки системы
  • POSTBOOT - после загрузки
  • SHUTDOWN - при разгрузке системы
  • null - контроль доступа вне зависимости от стадии работы системы

Обычно тип ACL просто не указывается (null) - для постоянного контроля, а первые три типа используются для ослабления определенных ограничений.

Субъект - это приложение, которому предоставляется доступ (режимы доступа описаны выше) к объекту - файлу или каталогу. Последнее поле, наследование, определяет, будет ли ACL наследоваться дочерними процессами или нет, и может принимать значения 0, 1 и -1.

Объект и субъект тесно связаны друг с другом. Например, субъекту /usr/bin/sshd (демону SSH) нужен доступ к объекту /var/run/sshd.pid. Вы определяет доступ, например, WRITE. Но вы должны понимать, что данное правило определяет доступ только данного субъекта к данному объекту, оно не относится к другим субъектам. Если же поле Субъект пусто (то есть субъект не указан), то данный режим доступа применяется к объекту для любого субъекта (для любого процесса).

Многие приложения (особенно shell-сценарии) вызывает другие программы во время своего выполнения, что нужно учитывать при разработке ACL. По умолчанию наследование выключено, и дочерние процессы не наследуют режимы доступа, определенные для родительского процесса. Такой режим работы может стать настоящей головной болью для администратора - ведь вам придется установить режим доступа для каждого процесса, вызываемого сценарием. Наследование можно включить, установив значение 1 поля наследования - это так называемый не рекурсивный режим наследования, то есть режим доступа будет унаследован только дочерним процессом. Если же вы хотите, чтобы режим доступа был унаследован не только дочерним процессом, но и всеми его потомками (его дочерними процессами), установите рекурсивный режим - значение -1 для поля Наследование.

Lids.conf

ACL хранятся в файле /etc/lids/lisd.conf. Открыв этот файл, вы увидите, что правила записаны в не совсем понятном для человека виде. Но вам не нужно редактировать этот файл вручную - для этого вам нужна утилита lidsconf. Но прежде, чем мы перейдем к рассмотрению lidsconf, вам нужно все-таки знать, что означают все эти числа:

0:0::1:0:1114128:834:/sbin:0-0
0:0::1:0:1933326:834:/bin:0-0
...

ACL системы LIDS содержит номера инодов вместо имен файлов, например, если мы установим режим APPEND для /var/log/messages, LIDS сохранить в ACL номер инода этого файла. Это позволяет более жестко контролировать доступ к файлу - ведь имя ничего не означает, главное - инод: можно удалить файл с именем /var/log/messages и заново создать файл с таким же именем. Имя не изменится, а номер инод - да.

Lidsconf

Начиная со второй версии, для администрирования и конфигурирования LIDS используются две разные утилиты. Утилиту администрирования - lidsadm - мы уже рассмотрели. Осталось рассмотреть утилиту конфигурирования - lidsconf. Наиболее важными опциями lidsconf являются:

  • -A, --add: добавить запись
  • -C,--check: проверить существующие записи
  • -D, --delete: удалить запись
  • -Z, --zero: удалить все записи
  • -U, --update: обновить /dev и номера инодов
  • -L, --list: вывести все записи

Следующий пример показывает ACL по умолчанию, который поставляет вместе lidstools-2.2.5rc1 (для вашего удобства мы добавили в листинг номера строк):

# lidsconf -L

		Subject	ACCESS	inherit		Object
---------------
1)		Any file	READONLY:	0			/sbin
2)		Any file	READONLY:	0			/bin
3) 		Any file	READONLY:	0			/boot
4) 		Any file	READONLY:	0			/lib
5) 		Any file	READONLY:	0			/usr
6)		Any file	READONLY:	0			/etc
7)		Any file	DENY:		0			/etc/lids
8)		Any file	DENY:		0			/etc/shadow
9)		Any file	APPEND:		0			/var/log
10)		Any file	WRITE:		0			/var/log/wtmp
11)		/bin/login	READONLY:	0			/etc/shadow
12)		/bin/login	GRANT:		0			CAP_SETUID
13)		/usr/sbin/sshd	GRANT:		0			CAP_NET_ADMIN
14)		/bin/login	GRANT:		0			CAP_GETID

Если несколько правил применяется к одному объекту, будет использовано последнее правило. Это лучше всего продемонстрировать на примере каталога /etc: который указан в правилах 6, 7, 8 и 11. Сначала /etc объявляется как READONLY (только чтение), затем объекты /etc/lids и /etc/shadow делаются невидимыми (DENY). Поскольку субъект не указан (Any file - любой файл), то ограничение применяется к любому процессу. А в строке 11 READONLY-доступ к файлу /etc/shadow предоставляется только субъекту /bin/login.

Для добавления новых записей используется опция -A программы lidsconf:

lidsconf -A [тип ACL] [-s субъект] -o объект [-t с-по] [-i уровень] -j действие

Как видите, обязательными в этом случае являются только опции A, o и j:

lidsconf -A -o /etc/hosts.conf -j READ

Все опции нам понятны, кроме опции [-t с-по]. Данная опция позволяет указать установить время действия правила. Время указывается в формате ЧЧММ-ЧЧММ, например, чтобы правило действовало с 8-00 по 19-35, используй следующую опцию -t 0800-1935.

Для удаления записи используется синтаксис:

lidsconf -D [тип ACL] [-s субъект] [-o объект]

Мы можете указать субъект и/или объект - будут удалены все совпадающие правила. Можно также указать и тип ACL, например, POSTBOOT

Возможности

В предыдущем ACL, наверное, вы заметили действие GRANT, предоставляющее возможность CAP_SETUID. А возможности мы до этого и не рассматривали, поэтому самое время это сделать.

LIDS предоставляет расширенное использование возможностей (модуль возможностей (capability security module) должен быть отключен в ядре). Кроме стандартных возможностей Linux, LIDS предоставляет две собственные возможности:

  • CAP_HIDDEN: процессы с установленной возможностью CAP_HIDDEN не будут отображаться в /proc, что позволяет скрыть процесс от программы ps, lsof и top
  • CAP_INIT_KILL: если эта возможность выключена для демона, то он не будет получать KILL-сигналы

CAP_HIDDEN не гарантирует, что процесс будет полностью невидим: например, сетевой демон можно обнаружить с помощью netstat или с помощью сканера портов, а также по наличию файла /var/run/название.pid.

А теперь перейдем к CAP_INIT_KILL. Просмотрим дерево процессов с помощью pstree:

$ pstree -a
init)
  |-atd)
  |-(bdflush)
  |-crond)
  |-httpd)
  |   |-httpd)
  |   |-httpd)
  |   |-httpd)
  |   |-httpd)
  |-(keventd)
  |-(khubd)
  |-(kjournald)
  |-klogd) -x
...

В случае с CAP_INIT_KILL, демон определяется как процесс, исходящий непосредственно от init (PID init всегда равен 1). К сожалению, это недостаток. Поскольку демон не может получать сигналы, администратор не сможет ни остановить процесс (SIGKILL), ни перезагрузить процесс (SIGHUP). И ко всему этому некоторые процессы, например, Apache, которые "общаются" со своими "родственниками" с помощью сигналов, не смогут нормально работать. Если же вы хотите использовать CAP_INIT_KILL, первая проблема может быть решена с помощью LFS - отсюда разрешено отправлять процессам сигналы. А вот для решения второй проблемы, вы должны включить CAP_INIT_KILL для определенного процесса, например, для Apache. По-другому тут никак нельзя.

LIDS немного модифицирует возможность CAP_BIND_NET_SERVICE. Обычно данная возможность включается для процесса, которому нужно "привязаться" к привилегированному порту (с номером 0-1024). Но LIDS расширяет синтаксис этой возможности, позволяя указывать порт или диапазон портов, к которым разрешена "привязка" процесса. Например, для Apache раньше разрешалась привязка к любому привилегированному порту, а теперь мы можем четко указать, к каким именно портам разрешается привязываться этому сервису - к 80 и 443.

Ограниченный набор возможностей

Ограниченный набор возможностей - это список возможностей, которые доступны (но не обязательно установлены) процессу в системе. Если какая-то возможность не указана в этом списке, ее нельзя назначить процессу. То есть если раньше мы могли назначить любому процессу любую возможность, то сейчас мы можем назначить процессу возможность, перечисленную в его списке возможностей. Соответственно, для каждого процесса можно определить свои списки возможностей.

Конфигурация LIDS по умолчанию (/etc/lids.cap) разрешает все возможности, кроме следующих:

  • CAP_SETPCAP: возможность устанавливать возможности другого процесса
  • CAP_SYS_MODULE: возможность загружать и выгружать модули ядра
  • CAP_SYS_RAWIO: возможность прямого ввода/вывода, то есть доступа к файлам /dev/port, /dev/mem, /dev/kmem и также прямого доступа к дискам (например, /de/hda).
  • CAP_KILL_PROTECTED: возможность "убивать" защищенные процессы

Помните, что система X Window требует возможности CAP_SYS_RAWIO. Если вам нужна система X Window, установите эту возможность для исполнимого файла X.

Установка и модификация возможностей

Установка возможностей производится с помощью все той же утилиты lidsconf. Синтаксис добавления возможности такой же, как и добавления правила для файла, только используется действие GRANT для разрешения этой возможности. Добавим возможность запуска X Window:

lidsconf -A -s /usr/X11/bin/X -o CAP_SYS_RAWIO -j GRANT

В этом случае нужно конкретно указывать субъект правила - процесс, которому разрешается та или иная возможность. В вышеприведенном примере мы предоставляем возможность прямого ввода/вывода CAP_SYS_RAWIO процессу /usr/X11/bin/X. А теперь разрешим Web-серверу Apache привязываться к непривилегированному порту:

lidsconf -A -s /usr/sbin/httpd -o CAP_BIND_NET_SERVICE -j GRANT

Более безопасным будет вариант разрешения привязки Apache к портам 80 и 443. Синтаксис возможности не предусматривает задание единичных портов, а только диапазонов, поэтому мы будем использовать нулевые диапазоны 80-80 и 443-443:

lidsconf -A -s /usr/sbin/httpd -o CAP_BIND_NET_SERVICE 80-80,443-443 -j GRANT

Мы также рекомендуем установить для Apache возможность CAP_INIT_KILL, чтобы он мог "общаться" со своими потомками (но Apache это только один пример - не забывайте и о других сервисах, которые используют подобную форму IPC!):

lidsconf -A -s /usr/sbin/apache -o CAP_INIT_KILL -j GRANT

Реализация LIDS

Теперь, когда мы знаем, как работает LIDS и знакомы с ее основными опциями, можно приступить к практической реализации LIDS в нашей системе.

Помните, что разработка ACL для всей системы - очень трудная и объемная задача, поэтому, я рекомендую вам создать shell-сценарий, содержащий вызовы lidsconf. Первой командой будет lidsconf -Z - данная директива удаляет все ранее существующие ACL. Данный сценарий нужно поместить в /etc/lids, что сделает его невидимым за пределами LFS-сессии.

Защита системных программ

Какие же системные файлы и каталоги требуют защиты LIDS? Защищать нужно содержимое каталогов /bin, /sbin, /lib, /usr/bin, /usr/lib и /usr/sbin. В данные каталоги производится установка программного обеспечения и, если мы сделаем их доступными только для чтения (READONLY), это не позволит злоумышленнику записать троянские версии системных программ. Также не забудьте защитить каталоги /usr/local/bin и /usr/local/lib, если вы придерживаетесь стратегии установки программ в каталог /usr/local. Конечно, при установке новой программы защита этих каталогов может создать незначительные неудобства для администратора, но, поверьте, это стоит того.

/etc и /etc/shadow

Конфигурационные файлы - это другая область защиты. Подавляющее большинство файлов в этом каталоге требуют доступ в режиме "только чтение", поэтому можно сначала установить для всего каталога режим READONLY, а затем разрешить доступ в режиме WRITE к некоторым отдельным файлам - глобально или для определенных субъектов. Наиболее важными файлами в каталоге /etc являются passwd/passwd- и shadow/shadow-: вы должны запретить всем субъектам доступ к файлам shadow/shadow- (DENY), кроме субъектов /bin/login, su и /usr/sbin/sshd - им полагается доступ READONLY.

Но мы еще не учли утилиту /usr/bin/passwd. Ей нужен WRITE-доступ к файлу /etc/shadow, чтобы пользователь мог изменить свой пароль. Когда пользователь изменяет свой пароль, файл /etc/shadow создается заново, а не просто модифицируется. В результате чего изменяется инод файла, а поскольку LIDS привязывается к инодам, то после изменения инода файла, LIDS уже не будет защищать его - ведь нового инода нет в "базе данных" LIDS. Кроме этого, нужно предоставить программе passwd WRITE-доступ ко всему каталогу /etc, поскольку запись файла - это изменение каталога. Если на месте passwd будет эксплоит злоумышленника, это приведет к тому, что он сможет получить доступ ко всем файлам в каталоге /etc.

К сожалению, не существует простого способа решения этой проблемы: вы или должны использовать альтернативную схему аутентификации, например, LDAP, чтобы запретить пользователям изменять свои пароли, или открыть WRITE-доступ к /etc. Существует, правда, еще один способ - самый безопасный, но очень неудобный для администратора. Вы запрещаете WRITE-доступ к /etc, а чтобы изменить свой пароль пользователь должен будет обращаться непосредственно к вам. Вы сможете изменить пароль пользователя в LFS-сессии, заодно и проверите пароль на "стойкость". Такой вариант приемлем, если пользователей у вас не много - до 10 человек, учитывая то, что пароль они изменяют не часто, раздражать это особо вас не будет. А вот если пользователей 200... Если для вас обеспечение полной защиты каталога /etc слишком сложно, вы должны обеспечить хотя бы защиту ключевых файлов. Наиболее важными являются каталоги:

  • /etc/rc.d
  • /etc/rc.d/init.d

Возможности Теперь перейдем к файлу /etc/lids/lids.cap. Как уже было отмечено, следующие возможности должны быть запрещены:

  • CAP_SYS_RAWIO: возможность прямого ввода/вывода, то есть доступа к файлам /dev/port, /dev/mem, /dev/kmem и также прямого доступа к дискам (например, /de/hda).
  • CAP_SYS_PTRACE: возможность трассировки системных вызовов, производимых процессом
  • CAP_SETPCAP: возможность устанавливать возможности другого процесса
  • CAP_KILL_PROTECTED: возможность "убивать" защищенные процессы
  • CAP_SYS_MODULE: возможность загружать и выгружать модули ядра

Единственное приложение, которое требует первую возможность - это X11. Для всех остальных приложений все эти возможности должны быть отключены.

Определение требуемого доступа

Как определить, к каким файлам и каталогам нужно обращаться тому или иному приложению? Отслеживать системные вызовы open(), chdir(), mkdir() и др. - задача неблагодарная, но вам се же нужно будет через это пройти. Немного облегчить задачу позволяет LIDS-FAQ, расположенный по адресу http://www.lids.org/fids-faaq/lids-faq.html. В ней вы найдете ACL для различных приложений: login, su, MySQL, BIND, OpenSSH, Apache и др.

При самостоятельной разработке ACL для приложения, ACL которого вы не найдете в LIDS-FAQ, последовательность создания ACL следующая:

  • Проверьте, к каким файлам и каталогам приложению необходим доступ - это можно сделать с помощью ptrace. Какие файлы конфигурации использует программа? Будет ли программа записывать что-то в /var/run
  • Нужно ли приложению привязываться к привилегированному порту? Если, да, то для него нужно включить возможность CAP_BIND_NET_SERVICE, указав необходимый диапазон портов

Проверить ACL просто - запустите приложение при включенной защите LIDS. Если что-то пойдет не так, в /var/log/messages вы найдете соответствующее сообщение LIDS.

Пример ACL для DNS-сервера

Давайте рассмотрим пример ACL, позволяющий работать DNS-серверу на нашей машине. Наш ACL будет состоять из двух частей. Первая часть будет содержать общий набор правил, предоставляющих базовый доступ. Данная часть универсальна - она подойдет не только для DNS-сервер, но и различных других приложений, запущенных в Linux-системе. Во второй части будут описаны специфические для DNS-сервера правила, ограничивающие доступ к файлам, а также определяющие возможности DNS-сервера. Как было отмечено ранее, наш набор правил мы представим в виде shell-сценария, содержащего серию команд lidsconf.

Сперва нужно сделать системные исполнимые файлы и библиотеки доступными только для чтения. Обойти это ограничение можно только в LFS-оболочке. Итак, нам нужно защитить каталоги /bin, /sbin, /usr и /opt:

/sbin/lidsconf -A -o /bin -j READONLY
/sbin/lidsconf -A -o /sbin -j READONLY
/sbin/lidsconf -A -o /usr -j READONLY
/sbin/lidsconf -A -o /opt -j READONLY

Мы не определили субъект, поэтому определенные нами объекты будут доступны только для чтения всем процессам в системе. Помните, что ACL наследуется, то есть доступ READONLY получат также и все подкаталоги указанных нами каталогов. Также следует помнить, что наследование не распространяется на подмонтированные файловые системы. Например, если к /usr/local подмонтирован другой раздел, то правила, примененные к /usr, не будут распространяться на файлы и каталоги, находящиеся на другом разделе.

Кроме этих каталогов, нам еще нужно защитить каталоги /etc и /boot. Однако, как было отмечено ранее, предоставление READONLY-доступа к каталогу /etc довольно проблематично, поэтому мы сконцентрируемся на защите ключевых файлов этого каталога. Наибольший интерес для злоумышленника представляются именно эти файлы, например, файл /etc/exports определяет экспортируемые файловые системы, а измени файл /etc/resolv.conf, он может перенаправить запросы нашего резолвера на свой DNS-сервер, который будет предоставлять неправильную информацию.

/sbin/lidsconf -A -o /boot 				-j READONLY
/sbin/lidsconf -A -o /etc/HOSTNAME			-j READONLY
/sbin/lidsconf -A -o /etc/apache			-j READONLY
/sbin/lidsconf -A -o /cron.daily			-j READONLY
/sbin/lidsconf -A -o /cron.hourly			-j READONLY
/sbin/lidsconf -A -o /cron.weekly			-j READONLY
/sbin/lidsconf -A -o /exports				-j READONLY
/sbin/lidsconf -A -o /hosts 				-j READONLY
/sbin/lidsconf -A -o /hosts.allow			-j READONLY
/sbin/lidsconf -A -o /hosts.deny			-j READONLY
/sbin/lidsconf -A -o /hosts.equiv			-j READONLY
/sbin/lidsconf -A -o /identd.conf			-j READONLY
/sbin/lidsconf -A -o /ld.so.conf			-j READONLY
/sbin/lidsconf -A -o /login.access			-j READONLY
/sbin/lidsconf -A -o /login.defs			-j READONLY
/sbin/lidsconf -A -o /logrotate.conf			-j READONLY
/sbin/lidsconf -A -o /mail				-j READONLY
/sbin/lidsconf -A -o /modules.conf			-j READONLY
/sbin/lidsconf -A -o /named.conf			-j READONLY
/sbin/lidsconf -A -o /networks				-j READONLY
/sbin/lidsconf -A -o /ntp.conf				-j READONLY
/sbin/lidsconf -A -o /resolv.conf			-j READONLY
/sbin/lidsconf -A -o /rc.d				-j READONLY
/sbin/lidsconf -A -o /services				-j READONLY
/sbin/lidsconf -A -o /shells				-j READONLY
/sbin/lidsconf -A -o /ssh				-j READONLY
/sbin/lidsconf -A -o /sudoers				-j READONLY
/sbin/lidsconf -A -o /sudoers.conf			-j READONLY
/sbin/lidsconf -A -o /etc/				-j READONLY

В зависимости от установленных в вашей системе пакетов, возможно, вам придется добавить другие фалы в этот список. Мы же описали наиболее критичные файлы. Также не нужно забывать про файлы журналов, находящиеся в каталоге /var/log. Для большинства файлов можно установить режим APPEND, и только для некоторых из них - режим WRITE, но только для определенных субъектов - login, init и halt:

/sbin/lidsconf -A -o /var/log				-j APPEND

/sbin/lidsconf -A -s /bin/login -o /var/log/wtmp	-j WRITE
/sbin/lidsconf -A -s /bin/login -o /var/log/lastlog	-j WRITE

/sbin/lidsconf -A -s /sbin/init -o /var/log/wtmp	-j WRITE
/sbin/lidsconf -A -s /sbin/init -o /var/log/lastlog	-j WRITE

/sbin/lidsconf -A -s /sbin/halt -o /var/log/wtmp	-j WRITE
/sbin/lidsconf -A -s /sbin/halt -o /var/log/lastlog	-j WRITE

Благодаря этим ограничениям, злоумышленник, получивший root-доступ, не сможет отредактировать эти файлы, чтобы скрыть свое присутствие. Недостаток этого метода заключается в том, что утилита logrotate не сможет больше функционировать, но всему есть своя цена. Теперь за "уборку" журналов отвечаете лично вы - администратор. Чтобы logrotate работала, ей нужно предоставить WRITE-доступ ко всему каталогу /var/log, но я не рекомендую это делать, поскольку злоумышленник может запустить logrotate много раз подряд - до тех пор, пока из журнала не удалятся следы его присутствия. Отключите logrotate и "чистить" журналы вручную. Во многих системах logrotate вызывается демоном cron, чтобы этого не происходило, нужно удалить файл /etc/cron.daily/logrotate или закомментировать его содержимое.

Теперь вернемся к нашим правилам. Нам нужно определить, как named взаимодействует с системой - мы должны предугадать все файлы, к которым понадобится доступ приложению, а также определить возможности для приложения. Сперва запретим доступ ко всей файловой системе:

/sbin/lidsconf -A -s /usr/sbin/named -o / -j DENY

BIND должен получить доступ к файлу конфигурации (/etc/named.conf) и к файлам зоны (каталог /var/named):

/sbin/lidsconf -A -s /usr/sbin/named -o /etc/named.conf		-j READ
/sbin/lidsconf -A -s /usr/sbin/named -o /var/named		-j READ

Как и любой другой демон, named записывает свой PID в файл, расположенный в каталоге /var/run. Обычно этот файл называется /var/run/named.pid. Мы должны разрешить приложению создавать файл с таким именем:

/sbin/lidsconf -A -s /usr/sbin/named -o /var/run/named.pid -j WRITE

На данный момент мы позаботились обо всех файлах, которые нужны демону named. Теперь нужно определить, какие ему нужны библиотеки. Для этого мы будем использовать программу strace, которая покажет все системные вызовы, а вместе с ними и все внешние файлы. Опция -f не позволяет приложению перейти в фон:

# strace -f -o named_trace named

Вывод программы named будет записан в файл named_trace. Демон named должен поработать несколько часов, после этого завершите процесс (named, а не strace!) и проанализируйте файл named_trace:

# cat namd_trace | grep open

Данная команда выведет все вызовы open() - вы увидите не только все файлы, которые используются приложением, но и режимы, в которых они используются. На основании этого списка мы можем составить такой список правил LIDS:

/sbin/lidsconf -A -s /usr/sbin/named -o /			-j DENY
/sbin/lidsconf -A -s /usr/sbin/named -o /usr/lib		-j READ
/sbin/lidsconf -A -s /usr/sbin/named -o / lib			-j READ
/sbin/lidsconf -A -s /usr/sbin/named -o /usr/share/locale	-j READ
/sbin/lidsconf -A -s /usr/sbin/named -o /etc/ld.so.preload	-j READ
/sbin/lidsconf -A -s /usr/sbin/named -o /etc/ld.so.cache	-j READ
/sbin/lidsconf -A -s /usr/sbin/named -o /etc/localtime	-j READ
/sbin/lidsconf -A -s /usr/sbin/named -o /etc/rndc.key		-j READ
/sbin/lidsconf -A -s /usr/sbin/named -o /var/log		-j APPEND
/sbin/lidsconf -A -s /usr/sbin/named -o /dev/random		-j READ

Данный список правил несколько упрощен, поскольку named использует много библиотек в /usr/lib и /lib, но проще предоставить READ-доступ к этим каталогам, чем прописывать отдельно каждую библиотеку. Теперь пришла очередь установки возможностей. прежде всего разрешим named привязываться к порту 53:

/sbin/lidsconf -s /usr/sbin/named -o CAP_NET_BIND_SERVICE 53-53 -j GRANT

При запуске named с опцией -u <имя пользователя>, он снижает свои привилегии до уровня обычного пользователя, указанного с помощью опции u. Поэтому нужно разрешить ему производить вызовы SUID и SGID:

/sbin/lidsconf -s /usr/sbin/named -o CAP_SETUID 53-53		-j GRANT
/sbin/lidsconf -s /usr/sbin/named -o CAP_SETGID 53-53		-j GRANT

Если BIND запускается в chroot-окружении, нужно установить возможность CAP_SYS_CHROOT:

/sbin/lidsconf -s /usr/sbin/named -o CAP_SYS_CHROOT -j GRANT

Как и у Apache, у BIND может быть несколько потомков, которым будет нужен доступ ко всем файлам и возможностям, описанным ранее, поэтому для переноса возможностей другим процессам нужно разрешить возможность CAP_SYETPCAP:

/sbin/lidsconf -s /usr/sbin/named -o CAP_SYETPCAP -j GRANT

Теперь самое время протестировать созданный ACL. Запустите named и следите за системными журналами - в них вы найдете сообщения об ошибках, если что-то пойдет не так.

В завершение нужно сказать, что если у вас возникли проблемы с тем или иным сервисом, посетите http://www.lids.org - там вы найдете много уже готовых ACL для разных сервисов.

SELinux

Security Enhanced Linux (SELinux) - это проект агентства национальной безопасности США (U.S. NSA). Сами понимаете, репутация такого ведомства говорит о серьезности проекта - там к безопасности относятся очень строго. Да и сам проект получился очень удачным - SELinux входит в состав многих современных дистрибутивов и устанавливается по умолчанию (правда, тоже по умолчанию, не активизируется).

SELinux организует в ядре своеобразную MAC-модель (используя комбинацию моделей DTE и RBAC). Система SELinux предлагает детализованный контроль привилегий, предоставляемых пользователю и процессу. SELinux - это не просто система безопасности, это переход с традиционной DAC-системы ("все или ничего" - у вас либо полный контроль над системой, либо вообще нет контроля), в которой решения о предоставлении доступа базировались на ID пользователя и правах файлов, в другое измерение безопасности. Чтобы показать, насколько безопасна эта система, в Интернете всем желающим предоставлялся root-доступ к машинам NSA. Цель эксперимента заключалась в следующем: сможет ли кто-то получить контроль над системой, на которой установлена SELinux, при условии, что у него будут права root. Пока никто этого не смог сделать.

Первоначально SELinux поставлялась как патч для ядра (2.2 или 2.4), сейчас она полностью поддерживает концепцию LSM и поставляется в виде LSM-модуля.

Сейчас поддержка SELinux есть в дистрибутивах Fedora Core, Debian и Gentoo. Примечательно, что Fedora Core стал первым дистрибутивом, где SELinux устанавливалась по умолчанию, но не активизировалась, поскольку настройка SELinux для начинающего пользователя - очень сложная (если не сказать непосильная) задача.

Наибольший недостаток SELinux - это ее сложность настройки. Система действительно сложна в настройке, а поскольку многие администраторы с ней не знакомы, они не могут ее полностью правильно настроить, что приводит к "дырам" в безопасности. Для полной настройки системы необходимо потратить несколько недель.

Для каждого пользователя и для каждого приложения в SELinux должны быть заданы правила, что отнимает много времени, особенно на многопользовательской рабочей станции. Поэтому часто SELinux используется на серверах, которые выполняют всего одну задачу, например, DNS-сервер, почтовый сервер или Web-сервер.