Личный блог Suvan`a.

Работая и играя с Linux... И что из этого иногда получается.

Пример ACL для DNS-cepвepa.

Рубрика: Безопасность -> Управление доступом
Метки: | | |
Среда, 15 июля 2009 г.
Просмотров: 5456

Рассмотрим пример 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 -А -о /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 /Id.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 /red -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 -А -о /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 -о / -j DENY

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

/sbin/lidsconf -A -s /usr/sbin/named -о /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 -о /var/run/named.pid -j WRITE

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

# strace -f -о named_trace named

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

# cat namd_trace | grep open

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

/sbin/lidsconf -A -s /usr/sbin/named -о / -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/Id.so.preload j READ

/sbin/lidsconf -A -s /usr/sbin/named -o /etc/Id.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 -о CAP_NET_BIND_SERVICE 53-53 -j GRANT

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

/sbin/lidsconf -s /usr/sbin/named -о 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 -о CAP_SYS_CHROOT -j GRANT

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

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

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

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