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

---

Использование LIDS для защиты системы

Колисниченко Денис aka dhsilabs (dhsilabs@mail.ru, dkws.org.ua)

LIDS (Linux Intrusion Detection System) представляет собой мощнейшую систему обнаружения и защиты от вторжения. За счет использования LIDS у администратора появляется много новых возможностей для увеличения безопасности Linux. Эта система позволяет ограничивать доступ к файлам, памяти, блочным устройствам, сетевым интерфейсам и запущенным программ, скрывать процессы от таких утилит, как ps, top, lsof, и даже опечатывать ядро, т.е. запрещать загрузку и выгрузку модулей ядра. Помимо всего прочего, в состав LIDS входит детектор сканирования портов и отличная система журналирования событий. Сегодня мы настроим эту IDS таким образом, что даже если злоумышленнику удастся воспользоваться уязвимостью в сетевом демоне и заполучить права root'а, он все равно не сможет нанести нашей системе сколь-нибудь серьезный ущерб.

Как установить систему?

Система LIDS состоит из патча ядра и набора пользовательских утилит lidstools. Все это можно скачать на сайте www.lids.org/download.html. На данный момент существуют патчи для ядер веток 2.4 и 2.6. Скачиваем соответствующий патч (в моем случае это lids-2.2.1rc2-2.6.11.6.tar.gz) и набираем следующие команды:

# cd /usr/src
# tar -zxvf lids-2.2.x-2.6.x.tar.gz
# cd linux-2.6.x
# patch -p1 < /usr/src/lids-2.2.x-2.6.x/lids-2.2.x-2.6.x.patch
# make menuconfig

Теперь приступим к конфигурированию ядра. Первым делом включи поддержку алгоритма SHA256, необходимого для работы LIDS (меню Cryptography Options/Cryptography API). Также убедись, что не установлено расширенное использование возможностей (модуль capability security module) и выключена SELinux, иначе LIDS будет конфликтовать с этими механизмами. После этого установи опции самой 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 только пользователям, физически работающим с машиной.

Сохраняем конфиг и компилируем ядро:

# make bzImage
# make modules
# make modules_install
# make install

Копируем свежеиспеченное ядрышко в каталог /boot

# cp arch/i386/boot/bzImage /boot/bzImage-2.6.xx-lids

Теперь добавь следующие строки в grub.conf:

ХХХХХХХХХХХХХХХХХХX
# vi /boot/grub/grub.conf
ХХХХХХХХХХХХХХХХХХX
title LIDS 
    root (hd0,0)
    kernel /boot/bzImage-2.6.xx-lids ro root=/dev/hda5
ХХХХХХХХХХХХХХХХХХX

Не забудь при этом изменить свою корневую файловую систему (у меня это /dev/hda5). Если у тебя LILO, а не GRUB, то в файл /etc/lilo.conf нужно добавить:

ХХХХХХХХХХХХХХХХХХX
# vi /etc/lilo.conf
ХХХХХХХХХХХХХХХХХХX
image=/boot/bzImage-2.6.xx-lids
    label="LIDS"
    root=/dev/hda5
ХХХХХХХХХХХХХХХХХХX

В случае с LILO чтобы внесенные изменения вступили в силу, требуется перезаписать загрузчик:

# lilo

Установка ACL

Для нормальной работы LIDS нужно обновить и скомпилировать поддержку списков контроля доступа. Делается это двумя командами:

# lidsconf -U
# lidsconf -C

Осталось только перезагрузить компьютер:

# reboot

Чтобы убедиться, что LIDS стартовала корректно (должны появиться сообщения об инициализации ACL-ов LIDS), после загрузки системы введи команду:

# dmesg | tail -n 11

Установка 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
# make install

При выполнении цели "make install" тебя попросят ввести пароль для администрирования LIDS: он не должен совпадать с паролем root.

Все, снова отправляем компьютер на перезагрузку:

# reboot

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

Сессии без 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 - начальные конфигурационные значения

"Опечатывание" ядра

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

Знакомьтесь: lidsadm

Администрирование LIDS выполняется с помощью lidsadm. Перечислю основные опции этой утилиты:

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

Ключ '-S' используется вместе с одним из следующих флагов:

• LIDS_GLOBAL - включить/выключить LIDS глобально
• RELOAD_CONF - перезагрузить файл lids.conf и обновить список защищенных инодов
• LIDS - включить/выключить LIDS локально, то есть создать LFS
• ACL_DISCOVERY - используется для отладки; когда включена, нарушения правил не запрещаются
• * SHUTDOWN - переключается в состояние shutdown

Перечисленные флаги должны предваряться знаком '+' (включить) или знаком '-' (выключить). Приведу две полезные команды (вход в LFS и выключение LIDS):

# lidsadm -S - -LIDS
# lidsadm -S - -LIDS_GLOBAL

Поговорим об ACL

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

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

• DENY - доступ к файлу запрещен
• READ - объект может быть открыт в режиме "только чтение", запись запрещена
• APPEND - объект может быть открыт для чтения или добавления информации, данный режим удобно использовать для файлов журналов
• WRITE - операции чтения и записи не ограничиваются, LIDS не защищает этот файл

В LIDS ACL описывается следующим образом:

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

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

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

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

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

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

Выведи все записи и обрати внимание на правила для каталога /etc:

# lidsconf -L
Any file	READONLY:	0	/etc
Any file	DENY:		0	/etc/lids
Any file	DENY:		0	/etc/shadow
…
/bin/login	READONLY:	0	/etc/shadow

Сначала /etc объявляется как READONLY (только чтение), затем объекты /etc/lids и /etc/shadow делаются невидимыми (DENY). Поскольку субъект не указан (Any file - любой файл), то ограничение применяется к любому процессу. Из последней строки видно, что субъекту /bin/login предоставляется доступ только для чтения к файлу /etc/shadow. Для добавления новых записей используется опция '-A' программы lidsconf:

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

К примеру:

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

Опция [-t с-по] позволяет установить время действия правила. Время указывается в формате ЧЧММ-ЧЧММ.

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

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

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

Особые возможности LIDS

Помимо всего прочего, LIDS предоставляет две интересные возможности:

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

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

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

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

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

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

Система X.Org требует возможность CAP_SYS_RAWIO, поэтому если ты используешь графический сервер, установи эту возможность для исполняемого файла X.

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

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

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

А теперь разрешим Web-серверу Apache привязываться к непривилегированному порту:

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

Более безопасным будет вариант разрешения привязки Apache к портам 80 и 443:

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

Синтаксис команды требует указания диапазона портов, поэтому чтобы указать один порт (например, 80), нужно указать 80-80.

Практика

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

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

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

Кроме этого, программе passwd нужно предоставить WRITE-доступ ко всему каталогу /etc, поскольку запись файла - это изменение каталога. Если на месте passwd окажется бинарик злоумышленника, то он сможет получить доступ ко всем файлам в каталоге /etc. К сожалению, не существует простого способа решения этой проблемы: нужно или использовать альтернативную схему аутентификации, например, LDAP, или открыть WRITE-доступ к /etc. Есть, правда, еще один способ - самый безопасный, но очень неудобный для администратора. Заключается он в запрещении WRITE-доступа к /etc, а для того, чтобы изменить свой пароль, пользователь должен будет обратиться непосредственно к админу.

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