17 April 2021
Использование 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, а именно:
Сохраняем конфиг и компилируем ядро:
# 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
Для нормальной работы LIDS нужно обновить и скомпилировать поддержку списков контроля доступа. Делается это двумя командами:
# lidsconf -U # lidsconf -C
Осталось только перезагрузить компьютер:
# reboot
Чтобы убедиться, что LIDS стартовала корректно (должны появиться сообщения об инициализации ACL-ов LIDS), после загрузки системы введи команду:
# dmesg | tail -n 11
Следующий шаг - установка пакета 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 и "опечатывание" ядра.
LFS представляет собой своеобразную оболочку, на выполнение команд которой не накладываются ограничения LIDS. Это позволяет администратору работать в системе как обычно, без выключения основной системы безопасности - ведь если LIDS функционирует, то ограничения накладываются даже на пользователя root. Однако LFS потенциально опасна: ведь если злоумышленнику удастся получить доступ к LFS, то он получит полный контроль над системой - вплоть до отключения LIDS. Доступ к LFS контролируется установленным ранее паролем. Дополнительно при конфигурации ядра можно указать терминалы, с которых разрешается доступ к LFS.
Обычно LFS используется админом для редактирования файлов в каталоге /etc/lids, который недоступен во время работы LIDS даже пользователю root. Как правило, в этом каталоге находятся следующие файлы:
С одной стороны загружаемые модули очень полезны, так как могут быть прилинкованы к ядру прямо во время работы ОС. С другой стороны, злоумышленник может добавить к ядру свои собственные модули, что никак не входит в наши планы. LIDS предлагает концепцию "опечатывания" ядра. В этом случае никто не может загрузить или выгрузить модуль. Опечатать ядро можно с помощью команды "lidsadm -I". Данную команду следует поместить в сценарии загрузки системы, только при этом не лишним будет проверить, что все необходимые модули загружены *до* выполнения команды "lidsadm -I".
Администрирование LIDS выполняется с помощью lidsadm. Перечислю основные опции этой утилиты:
Ключ '-S' используется вместе с одним из следующих флагов:
Перечисленные флаги должны предваряться знаком '+' (включить) или знаком '-' (выключить). Приведу две полезные команды (вход в LFS и выключение LIDS):
# lidsadm -S - -LIDS # lidsadm -S - -LIDS_GLOBAL
ACL используется для управления доступом к различным объектам, например, к файлам. В LIDS есть два типа ACL: ACL файлов (контролирует доступ к файлам и каталогам) и ACL возможностей (регулирует возможности исполняемых файлов).
LIDS определяет четыре режима для объектов:
В LIDS ACL описывается следующим образом:
<Тип ACL> <субъект> <объект> <доступ> <наследование>
Тип ACL определяет, на какой стадии работы системы будет контролироваться доступ к системе. Доступно четыре типа:
Обычно тип ACL не указывается, т.е. применяется умолчальное значение null для постоянного контроля доступа, а первые три типа используются для ослабления определенных ограничений. Субъект - это приложение, которому предоставляется доступ (режимы доступа описаны выше) к объекту - файлу или каталогу. Последнее поле, наследование, определяет, будет ли ACL наследоваться дочерними процессами или нет, и может принимать значения 0, 1 и -1.
ACL хранятся в /etc/lids/lisd.conf. Прямое редактирование этого файла невозможно. Чтобы внести изменения, следует воспользоваться lidsconf. Перечислю наиболее важные опции этой утилиты:
Выведи все записи и обрати внимание на правила для каталога /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 предоставляет две интересные возможности:
CAP_HIDDEN не гарантирует, что процесс будет полностью невидим: например, сетевой демон можно обнаружить с помощью netstat или с помощью сканера портов, а также по наличию файла /var/run/название.pid.
LIDS немного модифицирует возможность CAP_BIND_NET_SERVICE. Обычно данная возможность включается для процесса, которому нужно "привязаться" к привилегированному порту (с номером 0-1024). Но LIDS расширяет синтаксис этой возможности, позволяя указывать порт или диапазон портов, к которым разрешена "привязка" процесса.
Ограниченный набор возможностей - это список возможностей, которые доступны (но не обязательно установлены) процессу в системе. Если какая-то возможность не указана в этом списке, ее нельзя назначить процессу. Соответственно, для каждого процесса можно определить свои списки возможностей. Конфигурация LIDS по умолчанию (/etc/lids.cap) разрешает все возможности, кроме следующих:
Система 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.