Stfw.RuRoot под Прицелом
Хотя системным администраторам *nix систем не стоит беспокоятся о таких вещах, как сетевые или почтовые черви, кража root привилегий представляет реальную угрозу. Rhonda Thorne
🕛 25.01.2006, 01:45
Хотя системным администраторам *nix систем не стоит беспокоятся о таких вещах, как сетевые или почтовые черви, кража root привилегий представляет реальную угрозу. Уменьшая число знающих пароль root’а, устанавливая в расписании регулярный запрос на смену пароля и разрешая смену только пользователем (команда su) root, администраторы часто думают что они таким образом защитили свои системы. Однако кто-то, кому вы не доверяли управление системой, вполне реально может cкомпрометировать её. В этой статье будут представлены некоторые утилиты для помощи в выявлении и анализе возможных вторжений.Если у вас, как и у меня, на совести не одна система, за которой необходимо присматривать, то вы понимаете что нужно постоянно просматривать логи смен пользователей, файлы истории командной строки и файлы паролей. Мониторинг *nix’овых файлов при помощи автоматизирующих утилит пожалуй самый эффективный способ поддержки безопасности. Если вы используете систему HP 11.0, IDS/9000 систему обнаружения вторжения, то использование ниже описанных утилит скорее всего не даст ожидаемого эффекта.
Мой опыт составляет более шести лет, и следуя "Заповедям сисадмина", я применил всё, чему учился и был уверен, что возможность компрометации была минимальной. Однако, работая на большой проект Y2K, содержащий более 30 приложений, разработку программ и консультации по базам данных, я впервые столкнулся с проблемой в безопасности на уровне доступа root. К счастью, утилиты, обсуждаемые ниже, были под рукой и мне удалось выявить брешь безопасности, вычислить злоумышленника и узнать, какие команды были выполнены в процессе компрометации.
Как это было…
Я получил email, в котором сообщалось, что произошла su (смена пользователя) на root. Пользователь, переключившийся на root, не имел соответствующих прав. Я решил зайти в директорию, где хранился лог всех su на root через командную строку. Теперь я располагал именем пользователя, временем и датой этого события. Далее, я открыл этот файл и увидел, что этот человек выполнил вход в систему как root и запустил команду vi /etc/passwd. Первой моей реакцией было просмотреть файл /etc/passwd, где я нашел дополнительную запись для root, но с другим именем пользователя. Настоящий кошмар сисадмина - система скомпрометирована, и злоумышленник создал бэкдор с правами root.
При последующем просмотре истории командной строки и домашних директорий .sh_history, помимо общей проверки системы, единственным нанесенным ущербом оказался бэкдор и некоторые изменения разрешений в файлах баз данных. Я скопировал файл /etc/passwd, удалил бэкдор из активного файла /etc/passwd, относящийся к нему файл истории и файл sulog.
Закрыв бреши в безопасности, я собрал доказательства и информировал о произошедшем инциденте начальника отдела информационных технологий. При всех доказательствах, начальник не придумал ничего, кроме того, чтобы забыть об этом. Однако он был приятно удивлен быстротой моей реакции и скоростью восстановления системы и закрытия бреши в системе безопасности. Как бы то ни было, я получил кое-какой урок из случившегося и придумал метод оповещения при обнаружении root бэкдоров в файле /etc/passwd.
Эти утилиты не тестировались на линейке продуктов Linux, но должны работать при некоторых ухищрениях со скриптами. Методы были опробованы на платформах IBM AIX, HP-UX и Solaris. Установка:
Шаг 1: Принуждение su на root
Для того, чтобы всё это заработало, необходимо запретить пользователям проходить логин как root. Другими словами следует дать возможность пользователям получать права root только через команду su. Это приведет к записи в /var/adm/sulog и покажет имя пользователя, пытающегося получить доступ к root. Кроме того, будет создан отдельный файл в выбранной директории, содержащий историю командной строки (объяснение в шаге 2). Если вас не устраивает метод принуждения su, вы все равно можете воспользоваться методами оповещения (шаги 3 и 4). Следующие методы описывают принуждение su на root, что приводит к тому, что прямой вход как root можно будет выполнить только через консоль.
AIX:Можно использовать SMIT, чтобы обезопасить пользователей, изменить пользователя для root, и запретить удаленный вход. Если вы пользуетесь NIS, я рекомендую разобраться с этим подробнее, т.к. SMIT будет использовать "change user command" (chuser - команда смены пользователя). Страница man этой команды рекомендует не использовать эту команду, если запущен NIS, т.к. chuser изменяет только локальные файлы, не файлы NIS.
HP-UX: создайте файл /etc/securetty и добавьте слово CONSOLE. Поменяйте разрешение на файл - chmod 600 /etc/securetty, что приведет к запросу на права root для изменения этого файла.
Solaris: проверьте, что запись CONSOLE=/dev/console в файле /etc/default/login незакомментирована. Разрешения на /etc/default/login должны быть организованы таким образом, чтобы никто не мог изменить этот файл, кроме root, но чтобы права на чтение этого файла были у всех. Можно воспользоваться командой chmod 444 /etc/default/login.
Шаг 2: Перехват индивидуального входа root из истории командной строки
Чтобы поймать злоумышленника, и выяснить какие команды он выполнял, .profile root’а следует проверять на включение создания отдельных логов командной строки для каждого входа root. Осуществляется это при помощи добавления скрипта и установки оболочки Korn (ksh) в файле /etc/passwd:
who=`tail -1 /var/adm/sulog | cut -f6 -d " "` file=$who@`date +%T"-"%m%d%y sleep 1 HISTFILE=/var/adm/hist/$file HITSIZE=128 export HISTFILE HISTSIZE
Solaris: Вы можете расположить оболочку входа в систему /bin/ksh в /etc/passwd, заменив при этом /sbin/sh, установленный по умолчанию. Не повторяйте моей ошибки /sbin/ksh - это неверная оболочка и вам не удастся войти как root.
Проверьте, что вы закрыли доступ к .profile root'а. Сделать это можно командой chmod 700 .profile, в результате чего никто не сможет даже прочитать .profile. Таким образом истории командной строки каждого пользователя будут хранится отдельно, пока используется оболочка Korn с параметром истории командной строки esc k.Если пользователь или злоумышленник не использует su - когда переключается на root, то эти файлы историй будут храниться в домашней директории злоумышленника (файл .sh_history). Это приводит к тому, что расследование вторжения станет сложным (или вообще невозможным), ведь злоумышленник может почистить свой файл .sh_history. Если это и есть точка перегиба и объяснить пользователям о принуждении su нереально, вы можете сделать выбор между утилитой sudo для постоянных пользователей, которым нужны права root при выполнении некоторых задач, или принуждением su - только для администраторов.
В этом примере я использую имя директории /var/adm/hist, тогда как другие события в системы хранятся в /var/adm. Проверьте что вы установили правильное разрешение на директорию (chmod 777), таким образом все пользователи будут иметь разрешение на запись. Кроме того, я выполнял chown root:sys /var/adm на AIX и HP, а root:other на Solaris. Имя файла должно иметь формат: значение su и дата:время-год (rthorne-root@13:42:20-021302). Это необходимо для быстрого обнаружения вторжения и правильного определения времени. Не забудьте установить root’овую запись crontab для очистки файлов hist в целях экономии дискового пространства.
Шаг 3: Оповещание Активности su
#!/usr/bin/ksh #Name: security.chk #Written by Rhonda Thorne #Date 02/98 #Purpose is to report via email any su's to root on a daily basis echo "Here are the su to root list for yesterday" >> /tmp/sec.list grep `date +%m/%d` /var/adm/sulog|grep -e "-root" >> /tmp/sec.list mailx -s "su list" sysadmin2 < /tmp/sec.list rm /tmp/sec.list
Этот скрипт проверяет файл /var/adm/sulog на содержание события su на root и отправляет отчет на email. Заметьте, что знак «+» в sulog означает успешное выполнение команды, а знак «-» - неудачное (в любом случае следует исследовать это событие). Способ оповещения можно сменить. Я сделал запись в файле /etc/mail/aliases для sysadmin2, но вы можете жестко прописать адрес оповещения в самом скрипте. Поместите запись в файл crontab (root) для запуска скрипта по расписанию, но делайте это до полуночи, т.к. будет происходить проверка для su на текущую дату. В этом примере я назвал запись security.chk. Помните, что злоумышленник может проверить crontab на наличие проверок такого рода.
Solaris: Чтобы заставить работать grep -e, следует иметь /usr/xpg4/bin в корне .profile PATH или поместить эту запись в ваш скрипт (grep `date +$m/%d` /var/adm/sulog | /usr/xpg4/bin/grep -e "-root").
Шаг 4: Проверка Файла /etc/password на Root Back Doors
#!/usr/bin/ksh #Name: passwd.chk #Written by Rhonda Thorne #Date 04/98 #This script is to check the /etc/passwd file for duplicate root UID #entries (root back doors) count=`grep :0:3:/etc/passwd|wc -l` if [ $count -gt 1 ] then echo "Passwd file has a root back door. INVESTIGATE!" > \ /tmp/passwd.lst echo "Here is the su to root list" >> \ /tmp/passwd.lst grep `date +%m/%d` /var/adm/sulog|grep -e "-root" >> \ /tmp/passwd.lst mailx sysadmin-page < /tmp/passwd.lst else exit fi rm /tmp/passwd.lst
Этот скрипт проверяет файл паролей на root бэкдоры. Как и в шаге 3, можно выбрать способ оповещения. Я выбрал отображение при обнаружении активности бэкдора. Кроме того, а добавил запись /etc/mail/aliases для sysadmin-page, но вы также можете прописать адрес оповещение в скрипте. Поместите запись в файл crontab (root) для запуска скрипта по расписанию. Не забудьте назвать этот скрипт так, чтобы злоумышленнику было трудно догадаться о том, что происходит проверка на бэкдоры в то время, когда он будет просматривать crontab. Некоторые сисадмины преднамеренно добавляют записи root’овых бэкдоров в passwd в целях администрирования. Если вы относитесь к их числу, поменяйте -gt 1 на число root’овых записей в passwd, которое считается нормальным для вашей системы.
AIX: Поменяйте строку счета в скрипте на :0:0:, которая является UID/GID root’а. При поиске всего лишь :0:, скрипт может оповестить об ошибочных результатах поиска.
HP-UX: Поменяйте строку счета в скрипте на :0:3:, которая является UID/GID root’а, потому что некоторые системы используют значение UID=0 для пользователя system.
Solaris: Поменяйте строку счета в скрипте на :0:1:, которая является UID/GID root’а, потому что некоторые системы используют значение UID=0 для пользователя system. Чтобы заставить работать grep -e, следует иметь /usr/xpg4/bin в корне .profile PATH, или поместить эту запись в ваш скрипт, как показано в шаге 3.
Заключение
Надеюсь, что вы посчитаете эти методы полезными. Проактивные средства оповещения будут поддерживать вашу связь с системой, но я желаю, чтобы вам эта информация никогда не понадобилась. Возможно, это мечта любого сиспадмина.