LIDS::Журнал СА 4.2003
www.samag.ru
     
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
О журнале
Журнал «БИТ»
Информация для ВАК
Звезды «СА»
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Игры
Контакты
   

  Опросы

Какие курсы вы бы выбрали для себя?  

Очные
Онлайновые
Платные
Бесплатные
Я и так все знаю

 Читать далее...

1001 и 1 книга  
27.03.2019г.
Просмотров: 542
Комментарии: 0
Arduino Uno и Raspberry Pi 3: от схемотехники к интернету вещей

 Читать далее...

27.03.2019г.
Просмотров: 451
Комментарии: 0
Автоматизация программируемых сетей

 Читать далее...

27.03.2019г.
Просмотров: 477
Комментарии: 0
Изучаем pandas. Второе издание

 Читать далее...

27.03.2019г.
Просмотров: 406
Комментарии: 0
Компьютерное зрение. Теория и алгоритмы

 Читать далее...

13.03.2019г.
Просмотров: 608
Комментарии: 0
DevOps для ИТ-менеджеров

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

 LIDS

Архив номеров / 2003 / Выпуск №4 (5) / LIDS

Рубрика: Безопасность /  Механизмы защиты

СЕРГЕЙ ЯРЕМЧУК

LIDS

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

Пользователи имеют определенные права доступа, на основании которых решается вопрос о том, может ли процесс, имеющий определенные атрибуты (владелец, группа), открыть файл для работы с ним. Но такое упрощение имеет и свои видимые недостатки. Так, важные системные файлы получаются фактически не защищенными. Почему? Как правило, в грамотно настроенной системе такие файлы может изменять и удалять только суперпользователь. Но хорошо, когда это именно наш системный администратор, а если нет? Я считаю, что взломать аккаунт root в принципе возможно, но есть гораздо более эффективный и быстрый способ получить доступ к системным файлам. Так, известно, что большинство демонов (программ, выполняющих запросы пользователей) имеют установленный SUID/SGID-бит. Сущность его заключается в том, чтобы придать процессу, запущенному от имени обычного пользователя, несколько большие права в системе.

В качестве примера рассмотрим утилиту passwd, которая позволяет изменить пользователю свой пароль. Все учетные записи и пароли (в зашифрованном виде) хранятся в файлах /etc/passwd и /etc/shadow. Если предоставить право каждому пользователю самолично вносить изменения в эти файлы напрямую, то можете представить, что это будет. Естественно, вам никто и не даст такое право.

[sergej@grinder sergej]$ ls -l /etc/passwd /etc/shadow

-rw-r--r--  1 root  root  1628 Авг 13 18:31 /etc/passwd

-r--------  1 root  root  1081 Авг 13 18:31 /etc/shadow

Как видите, все пользователи имеют право только на чтение файла /etc/passwd, а записывать информацию может только root (а /etc/shadow, как вы видите, закрыли от всех остальных, чтобы пароли нельзя было подобрать). Теперь смотрим на утилиту passwd:

[sergej@grinder sergej]$ ls -l /usr/bin/passwd 

-r-s--x--x  1 root  root  15104 Мар 14 03:44 /usr/bin/passwd

Буква «s» означает, что установлен флаг SUID, а владельцем файла является его величество root и теперь, кто бы ни запустил утилиту на выполнение, на время работы программы он временно получает права суперпользователя, т.е. произвести запись в защищенный системный файл. Естественно, утилита должна (и делает это) производить изменение учетной записи только запустившего ее пользователя. Как вы понимаете, требования по безопасности к программам, использующим данный метод, должны быть повышены. Это, наверное, самая большая дыра во всех UNIX, потому что найдя ошибку в одной из программ, использующих биты SUID/SGID, можно производить любые действия, не обладая при этом правами суперпользователя.

Это свойство использовал нашумевший в 1988 году вирус Морриса. Теперь, получив доступ к такой программе, ничего не мешает переслать файл /etc/passwd себе по электронной почте или убить init, тем самым остановив работу сервера. Но с другой строны, к тому же файлу /etc/passwd при нормальной работе должны обращаться всего две программы: login – при входе пользователя в систему, и уже упоминаемая passwd при смене пароля. Но уж никак не Sendmail. Отсюда получаем, что процессы, запущенные от имени суперпользователя, имеют гораздо больше прав, чем им требуется. С одной стороны, количество SUID/SGID неуклонно уменьшается, но до нуля их количество вряд ли дойдет. Поэтому необходимо иметь способ вручную отрегулировать доступ к некоторым важным системным файлам и каталогам.

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

Итак, задачи поставлены, теперь хотелось бы иметь инструмент для их решения. Таким инструментом является LIDS (Linux Intrusion Detection System), который представляет из себя патч к ядру для осуществления принудительного контроля доступа в ядре, а также инструмент администрирования (lidsadm). Кроме того, LIDS встраивает в ядро механизм предупреждений о каких-либо опасных действиях, а также такую довольно полезную вещь, как детектор сканера портов, дающий сисадмину время на подготовку к отражению атаки. Ведь в большинстве случаев перед проникновением идет «разведка боем».

Для установки LIDS необходимо скачать с сайта проекта http://www.lids.org/install.html или с одного из его ftp-зеркал утилиту администрирования и патч к ядру. Все это находится в пакете lids-х.х.х-y.y.y.tar.gz, где х.х.х – номер версии утилиты lids, а y.y.y – номер версии ядра, для которого предназначен патч. Причем поддерживаются и так любимые системными администраторами ядра серии 2.2.х и современные 2.4.х, а также developer ядра серии 2.5.х. Я использовал lids-1.1.2rc4-2.4.19.tar.gz, поэтому с ftp://ftp.kernel.org было взято ядро linux-2.4.19.tar.bz2. Теперь распаковываем два скаченных файла.

# bzip2 -cd linux-2.4.19.tar.bz2 | tar -xvf -

# tar -zxvf lids-1.1.2rc4-2.4.19.tar.gz

Следующим шагом переходим в распакованный каталог с ядром и устанавливаем патч.

# cd linux_install_path/linux

# patch -p1 < /lids_install_path/lids-1.1.2rc4-2.4.19.patch

В случае если патч установился без проблем, обязательно нужно создать символическую ссылку /usr/src/linux на новый каталог с исходниками ядра.

# rm -rf /usr/src/linux

# ln -s linux_install_patch/linux /usr/src/linux

Теперь переходим в каталог с исходными текстами, конфигурируем и компилируем ядро.

# cd /usr/src/linux

# make xconfig (или make menuconfig)

В процессе конфигурирования необходимо обязательно установить следующие пункты. В «Code maturity level options» выставьте «Prompt for development and/or incomplete code/drivers».

Рисунок 1

В «General setup» – «Sysctl support».

Рисунок 2

И зайдя в новый пункт «Linux Intrusion Detection System» – «Linux Intrusion Detection System support (EXPERIMENTAL)».

Рисунок 3

После конфигурирования записываем внесенные изменения и выходим из программы конфигурации. После этого идет обычный процесс компиляции и установки нового ядра.

# make dep

# make clean

# make bzImage

# make modules

# make modules_install

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

# cp arch/i386/boot/bzImage /boot/lids-kernel

И в параметрах загрузчика (Grub или LILO) прописываем необходимые строки для запуска системы с новым ядром. Но перегружаться еще рано, теперь необходимо установить и сконфигурировать утилиту lidsadm. Если этого не сделать, то система попросту не загрузится. Не удаляйте старое ядро: в случае неудачи будет возможность загрузиться без LIDS для продолжения работы и выяснения причин. Итак, переходим в каталог с распакованной LIDS и даем стандартную команду для конфигурирования и установки.

# ./configure && make && make install

После установки можно обнаружить каталог /etc/lids/, в котором хранятся установки и настройки программы. Внутри находятся четыре файла:

  • lids.conf – в данном файле содержится информация о правах доступа (ACL – Access Control Lists) к различным файлам и каталогам.
  • lids.cap – в этом файле прописаны возможности по конфигурированию. Чтобы включить необходимое свойство, необходимо поставить «+» перед ним, отключить – «-».
  • lids.net – в этом файле устанавливаются необходимые значения для посылки предупреждающих сообщений с помощью e-mail (IP-адрес, порт, SMTP-сервер, заголовок). Для включения данной возможности необходимо собрать ядро с параметром «Send security alerts through network».
  • lids.pw – в этом файле сохраняется пароль, предназначенный для изменения параметров lids.

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

# lidsadm -P

Теперь у нас запросят пароль дважды и после окончания работы утилиты в зашифрованном виде его можно пронаблюдать в файле lids.pw. Для получения краткой справки по используемым командам и устанавливаемым флагам введите:

# lidsadm -h.

Теперь, чтобы добавить новое правило, воспользуемся опцией -A (append). Общий синтаксис команды такой:

lidsadm -A [-s subject] -o object [-d] -j

Поле ACTION указывает на действие, которое будет выполняться при запросе отмеченного ресурса. Оно может принимать несколько значений, но самыми употребляемыми будут четыре:

  • READ (объект помечен только для чтения);
  • APPEND (возможно только добавление информации);
  • WRITE (возможна запись, в том числе и удаление);
  • GRANT (предоставляет возможность субъекту отклонять общие правила).

Теперь введя команду:

# /sbin/lidsadm -A -o /etc/shadow -j DENY

мы запретим всем пользователям доступ к данному файлу. Теперь после перезагрузки с lids-ядром, просмотрев с помощью команды:

# ls /etc/shadow

в ответ получим ls: /etc/shadow : No such file or directory. Чтобы пользователь мог зарегистрироваться в системе, откроем доступ только для чтения единственной программе, которая законно должна работать с данным файлом.

# /sbin/lidsadm -A -s /bin/login -o /etc/shadow -j READ

Теперь пользователи получают возможность входить в систему (с помощью /bin/login), т.е. здесь достаточно прав только для чтения, а другим программам доступ будет заблокирован. Аналогичным образом можно установить требуемые действия сразу на весь каталог.

# /sbin/lidsadm -A -o /sbin/ -j READ

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

# /sbin/lidsadm -A -o /var/log/samba/ -j APPEND

# /sbin/lidsadm -A -o /var/log/secure -j APPEND

Просмотреть все установленные правила можно, воспользовавшись опцией -L (list):

# lidsadm -L

Статус системы можно просмотреть опцией:

# /sbin/lidsadm -V

После того как все необходимые правила будут занесены, необходимо обновить dev/inode лист с помощью команды:

# /sbin/lidsadm -U

Естественно, кроме добавления информации о защищаемых файлах, есть возможность удалить файл из списка. Это можно проделать, воспользовавшись опцией -D (delete) с указанием конкретного файла:

# /sbin/lidsadm -D /etc/httpd/

или с помощью команды lidsadm -Z очистить сразу весь список. И напоследок, после всех установок, необходимо «запечатать» ядро («seal the kernel») с помощью команды:

/sbin/lidsadm -I

а более грамотным решением будет занести в файл /etc/rc.local соответствующую строку, чтобы не вводить ее при каждом перезапуске системы. После этого ваша система будет защищена с помощью lids. А что делать, если понадобится временно убрать защиту, неужели опять придется перезагружаться со старым ядром? Совсем нет. Необходимо переключиться в режим LIDS free session (LFS). Для его поддержки при конфигурировании ядра необходимо установить параметр «Allow switching LIDS protections».

Чтобы открыть сеанс LFS в текущем терминале (и только в нем), необходимо ввести:

# /sbin/lidsadm -S -- -LIDS

и ввести пароль по запросу. Чтобы отказаться от режима LFS, вводим:

# /sbin/lidsadm -S -- +LIDS

Плюс ко всему желательно заставить перечитать lids конфигурационные файлы:

# /sbin/lidsadm -S -- +RELOAD_CONF

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

# /sbin/lidsadm -S -- -LIDS_GLOBAL

и теперь это будет обычная система. Как говорилось, lids может защищать процессы от посягательств извне. Установив в файле /etc/lids/lids.cap опцию -29:CAP_INIT_KILL, можно защитить все процессы, чьим родительским является процесс номер 1 в системе init. А вот так можно убрать (спрятать) из списков процессов, выдаваемых с помощью команды ps, сервер Apache.

# /sbin/lidsadm -A -s /usr/sbin/httpd -t -o CAP_HIDDEN -j INHERIT

В случае если lids «прижился» на компьютере и старое ядро за ненадобностью было удалено, есть возможность при загрузке lids-ядра установить режим загрузки без защиты. Для этого надо при выборе ядра в LILO или Grub дополнительно указать параметр:

security=0: grub>lids-kernel security=0

После этого система будет загружена в обычном незащищенном режиме.

При компиляции ядра с опцией «Port Scanner Detector in kernel» появится возможность дополнительно отслеживать работу сканеров портов, и в случае обнаружения такого сканирования, системный администратор будет оповещен, а в лог-файле появится информация, которая может помочь (а может и не помочь, скрыть IP-адрес труда особого не представляется, но это тема отдельного разговора) в поиске злоумышленника так, что такой возможностью пренебрегать не стоит. Вот такой он LIDS. Единственная сложность в конфигурировании – это определиться с каталогами, которые нужно будет защищать, и выбрать режим работы для них. Здесь универсальный совет дать трудно: все зависит от назначения компьютера и запущенных сервисов. Но не обязательно стараться закрыть все файлы, достаточно поначалу обойтись только наиболее важными, а затем постепенно наращивать защиту. В документации, поставляемой с пакетом LIDS, приведены примеры для некотрых наиболее часто используемых сервисов, так что по аналогии можно будет разобраться. Но одно ясно: используя LIDS, можно существенно поднять уровень защиты компьютера под управлением Linux и значительно усложнить жизнь тем, кто хочет покопаться в чужом компьютере.


Комментарии отсутствуют

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru