LXF89:Безопасность

Материал из Linuxformat.

Настоящая безопасность Как воспользоваться умными утилитами Linux и защитить вашу машину.

Безопасность: Ищем лазутчиков

ЧАСТЬ 5: Д-р Крис Браун заканчивает серию уроком обнаружения вторжений с помощью Aide и Tripwire – для администраторов это вроде дактилоскопии и, простите за милитаризм, сигнальной мины.

Как узнать, что вас «хакнули»? Это может быть неочевидно. Непрошеные гости не всегда портят сайты или вводят «здесь был Вася» в /etc/motd. Они могут втихую использовать ваш компьютер как, например, ретранслятор почты для рассылки спама.

На четырех предыдущих уроках мы рассмотрели активные способы повышения безопасности Linux-систем – другими словами, предотвращения взлома. На этом, финальном, уроке займемся парой инструментов, Tripwire и Aide, созданных для отслеживания несанкционированных изменений файловой системы. Эти инструменты по своей природе скорее реактивны – они не предотвращают атаку. Зато они смогут сообщить вам, что ваша безопасность под угрозой – и, уж поверьте мне, лучше знать об этом, чем не знать. Я научу вас настраивать их так, чтобы регулярные проверки не отвлекали ваше внимание на нормальные события.

Основа работы Tripwire и Aide одна: делается «снимок» состояния файловой системы (по крайней мере, значимых ее частей) в тот момент, когда есть уверенность в ее нетронутом состоянии. Затем с регулярными интервалами (желательно ежедневно, через расписание Cron) программа запускается снова, и состояние файловой системы сравнивается с исходным снимком. Составляется отчет с описанием изменений. Отчет можно сохранить на диск, а можно отослать по почте системному администратору. Учтите, эти отчеты действительно придется просматривать, если вы хотите, чтобы от инструментов обнаружения вторжений был прок. Вдумчивое использование grep может устранить некоторые излишества, но в конечном итоге отчет должен читать конкретный человек.

Сначала Aide

Начнем с Aide. Аббревиатура означает Automatic Intrusion Detection Environment (среда автоматического обнаружения вторжений), написали программу Рами Лехти [Rami Lehti] и Пабло Виролайнен [Pablo Virolainen]. Лехти учился в технологическом университете Тампере (Финляндия), и копию учебника по Aide до сих пор можно найти на университетском сайте по адресу: http://www.cs.tut.fi/~rammer/Aide/manual.html. Позднее проект был подхвачен Ричардом ван ден Бергом [Richard van den Berg] и Майком Маркли [Mike Markley] и приютился на http://sourceforge.net/projects/Aide. При желании оттуда можно загрузить исходный код. Однако для подготовки этого урока я не стал возиться с исходными текстами, а взял готовый пакет из состава SUSE Linux Enterprise Desktop 10 (можете воспользоваться любой другой свежей версией SUSE).

Ни одна уважающая себя программа не обходится без файла настроек. Aide – не исключение, но стандартная конфигурация совсем неплоха, так что перейдем сразу к делу (а с файлом разберемся позже). Для начала необходимо создать исходный снимок. Команда проста: aide --init. Делать это нужно тогда, когда вы уверены в целостности системы: например, сразу же после инсталляции с надежного носителя и начальной настройки, но перед подключением машины к сети (или, что случается чаще, перед продолжительным выходом в Интернет для закачки обновлений, предложенных дистрибутивом). Aide исследует файловую систему полностью, поэтому процесс занимает несколько минут.

Результат работы программы можно будет найти в /var/lib/Aide/Aide.db.new. Это обычный текстовый файл, а не двоичная копия всей файловой системы (а также не снимок логического тома, пригодный для отката к прежнему состоянию). Здесь содержится по строке на каждый файл, в которой записаны сведения об имени файла, правах доступа, принадлежности к пользователю и группе, размере, времени последнего изменения, времени последнего изменения статуса, номере inode, числе связей, а также один или больше дайджестов (криптографических хэшей) его содержания. Дайджесты дают возможность Aide отслеживать изменения в содержимом файла.

Теперь снимок нужно переименовать в aide.db, поскольку именно этот файл Aide будет разыскивать впоследствии:

# cd /var/lib/aide
# mv aide.db.new aide.db

Представьте, что удаленный взломщик поместил программу под названием cal в директорию /bin. А в Linux есть стандартная и совершенно безвредная программа с таким именем, так что мы и не заметим кукушонка, если не будем сверхбдительны и не запомним, что настоящая cal живет в /usr/bin. Смоделируем подозрительный процесс следующим образом:

# cp /bin/cp /bin/cal

Теперь запустим Aide в проверочном режиме (в реальности, повторимся, это следует делать через Cron):

# aide --check -V2
Aide found differences between database and filesystem!!
Start timestamp: 2006-10-03 05:56:39
Summary:
    Total number of files: 149004
    Added files: 2
    Removed files: 1
    Changed files: 3
----------------------------
  Added files:
----------------------------
  added:/var/lib/aide/aide.db
  added:/bin/cal
----------------------------
  Removed files:
----------------------------
  removed:/var/lib/aide/aide.db.new
----------------------------
  Changed files:
----------------------------
  changed:/etc/cups/certs
  changed:/etc/cups/certs/0
  changed:/bin

Нетрудно видеть, что Aide прилежно отметила добавление файла /bin/cal. Замечено также переименование aide.db.new в aide.db. Есть и третье сообщение, об изменении файла /etc/cups/certs/0. Что это? Честно говоря, сам не знаю. Это идет от системы печати CUPS, а обновляется каждые пять минут при любой погоде, но я не знаю, зачем. Мы узнали важную вещь: Aide присущи сигналы ложной тревоги (об изменениях, расцениваемых как подозрительные, но таковыми не являющимися).

Уточним поиск

Свойства файла в Aide

Рис. 1 Вы можете указать Aide те Свойства файлов, изменения которых вы считаете подозрительными.

В процессе повседневной работы файловая система меняется – как планово, так и неожиданно. Например, в домашней директории можно ожидать любых изменений; но системные утилиты вроде ps и ls не должны меняться никогда [разве что при крупном обновлении системы, – прим. ред.]. Вот и пришла пора заняться файлом настройки Aide (/etc/Aide.conf). Его основная задача – указать директории и файлы, за которыми нужно следить, а также свойства файлов, нуждающиеся в контроле. Как показано на Рис. 1, каждому параметру соответствует особый символ. Обратите внимание на параметры R и L: они определяются комбинацией базовых свойств. Можно задать и собственные комбинации в aide.conf, следующим образом:

Binlib = p+i+n+u+g+s+b+m+c+md5+sha1
Logs = p+i+n+u+g+S

Набор параметров Binlib (или называйте как хотите) объединяет в себе все свойства файла, включая его дайджест md5 и sha1, а также дайджесты. Взглянув на Рис. 1, мы заметим, что упущено лишь одно свойство, «a», время последнего доступа. Такой набор параметров подходит для системных утилит и библиотек, которые не должны изменяться никогда. Набор параметров Logs менее строг, он подойдет для файлов, которым позволено расти в размерах, например, файлов журналов.

Между прочим, назначение свойства «a» (времени последнего доступа) для меня загадка: я сомневаюсь, что оно когда-либо вам пригодится. Мне кажется, если к файлу нельзя даже притронуться, то проще зашифровать его или упрятать в безопасное место.

Главная часть файла конфигурации – правила, определяющие, какие части файловой системы и по каким критериям должна проверять Aide. Правила в основном совершенно несложные. Например, правило /lib Binlib означает, что Aide будет проверять всю файловую систему внутри /lib с помощью набора параметров Binlib, заданного ранее, и доложит обо всех приключившихся там изменениях. Левая часть правила (/lib в нашем случае) трактуется как регулярное выражение, которому должно удовлетворять имя файла (совпадение неявно привязано к началу имени). Таким образом, левая часть /lib будет соответствовать и /lib/libc.so.6, и /lib/security/pam_unix, но не будет соответствовать /var/lib/locatedb. Можно ограничить поиск, приписав к концу имени знак $: например, левая часть выражения /tmp$ будет соответствовать /tmp и ничему иному.

Вывести названия из-под проверки можно, добавив префикс !. Например, правило !/.*/BACKUP исключит все директории BACKUP, независимо от расположения в файловой системе. Особо отмечу, что .* в этом примере – регулярное выражение, а не маска имени файла.

Пишите собственные правила

Рис. 2 Сердце вашей следящей системы: простой, но информативный файл aide.conf.

На Рис. 2 приведен пример Aide.conf. В нем содержатся кое-какие глобальные настройки, усовершенствованные правила (наборы параметров) и несколько правил, определяющих те свойства файлов, которые нам хотелось бы видеть неизменными в каждой директории.

Пример конфигурационного файла Aide из SUSE Linux содержит «разумные» правила, и, конечно, лучше применять Aide со стандартным набором правил, чем не применять вообще. Но еще лучше поразмыслить над особенностями своей машины и выработать собственную политику безопасности и собственные наборы параметров. Процитирую разработчиков: «Неплохая идея – игнорировать постоянно меняющиеся директории, если вы не хотите получать слишком громоздкие отчеты. Лучше исключить временные директории, почтовые очереди, директории с файлами журналов, файловую систему /proc – все, что меняется регулярно. Проверять следует все системные двоичные файлы, библиотеки, include-файлы и исходные файлы системы».

Будучи не в меру мнительным (то есть запустив слишком частые или слишком строгие проверки), вы получите слишком много ложных сигналов, а в длиннющем отчете потонут указания на реальные проблемы, или, хуже того, отчет раздуется настолько, что вы вообще поленитесь его читать.

Aide может стать сердцевиной системы обнаружения вторжений, но это еще не комплексное решение. Неплохо будет добавить строчку в ваш файл Cron для ежедневного запуска Aide, а может быть, вы напишете сценарий оболочки для разумного распоряжения результатами (отправки кому-нибудь по почте?). Программа не лишена слабых мест, уязвимых для атак: ведь эрудированный злоумышленник может предполагать ее существование. Во-первых, сам исполняемый файл Aide может быть модифицирован с целью не допустить сообщения об инсталляции подозрительного руткита. Интервент может исказить файл конфигурации, исключив из него правила для «своих» файлов. Наконец, сметливый хакер может внедрить свое ПО, запустить aide --init вторично, и – концы в воду.

Беремся за Trip

Теперь обратим внимание на Tripwire [Tripwire – растяжка, – прим. пер.]. Если Aide твердо придерживается принципа открытости (и распространяется под GPL), Tripwire теперь принадлежит Tripwire Inc., где она развилась от простой программы проверки целостности файловой системы вроде Aide до (извините за рекламный пафос: я цитирую web-сайт) «всестороннего решения для аудита изменений, безопасности и соответствия для любых серверов Linux/Unix/Windows, баз данных, сетевых устройств, настольных машин и служб каталогов». Ого! Все это правда – только вот коммерческие версии Tripwire теперь далеки от центра внимания сообщества.

Но свободная версия Tripwire пока существует, и доступна по адресу: http://sourceforge.net/projects/Tripwire. Для целей данного урока я загрузил двоичную версию (файл Tripwire-2.4.0.1-x86-bin.tar.bz2) и установил ее в своей системе Fedora Core 5. Не обошлось без трудностей. При полном отсутствии хоть какого-то подобия инсталляционного скрипта, мне пришлось скопировать двоичные файлы, man-страницы и файлы конфигурации в нужные места вручную. В сети можно встретить Tripwire в виде различных RPM; инсталляция одного из них намного упростит вашу задачу.

Свойства файла в Aide

Рис. 3 У Tripwire масса исполняемых и настроечных файлов, баз данных и отчетов. Это – основные..

Концепция Tripwire во многом схожа с Aide, но административно она более сложна. На Рис. 3 показаны основные компоненты Tripwire. Усложнение частично происходит из-за того, что Tripwire шифрует свои файлы и снабжает цифровыми подписями, что устраняет нужду в защищенных носителях, предложенных мной для Aide. Поэтому существуют, например, текстовая и шифрованная версии конфигурационного файла, и такие же версии файла политики (в файле политики перечисляются файлы и директории для мониторинга, а также параметры проверки).

После инсталляции Tripwire необходимо создать общий (site-wide) и локальный (для каждого хоста) ключи шифрования. Для этого используйте twadmin, например вот так:

# twadmin -m G -S /etc/Tripwire/site.key
# twadmin -m G -L /etc/Tripwire/hostname-local.key

В каждом случае вам будет предложено ввести и подтвердить пароль, которым будет впоследствии открываться доступ. Общий ключ используется для защиты файлов, используемых на нескольких системах. Среди них – файлы конфигурации и файлы политик, мы до них скоро доберемся. Локальный ключ защищает файлы локальной машины, например, базу данных Tripwire. Локальный ключ можно использовать и для подписи проверочных отчетов.

У Tripwire два файла конфигурации. Первый, /etc/Tripwire/twcfg.txt, указывает расположение остальных операционных файлов Tripwire. Вот пример:

POLFILE = /etc/Tripwire/tw.pol
DBFILE = /var/lib/Tripwire/$(HOSTNAME).twd
REPORTFILE = /var/lib/Tripwire/report/$(HOSTNAME)-
$(DATE).twr
SITEKEYFILE = /etc/Tripwire/site.key
LOCALKEYFILE = /etc/Tripwire/$(HOSTNAME)-local.key
EDITOR = /bin/vim
REPORTLEVEL = 3

Этот файл нужно зашифровать и подписать. Сделайте это следующей командой:

# twadmin -m F -S site.key twcfg.txt

В результате будет создан файл tw.cfg. А во втором файле конфигурации, /etc/Tripwire/twpol.txt, как раз и содержатся все действия. Здесь вы устанавливаете правила, определяющие участки вашей системы, подлежащие мониторингу, и параметры проверки. Этот файл, в основном, подобен Aide.conf, рассмотренному ранее. В основном Tripwire поддерживает тот же набор атрибутов, что и Aide; они так похожи, что я не буду занимать место повторением, а просто отошлю вас к Рис. 1.

Как и Aide, Tripwire дает возможность задавать собственные наборы параметров (Tripwire называет их масками параметров) в виде комбинаций отдельных свойств файлов. Например, стандартный twpol.txt содержит следующие строки:

Growing = +pinugtdl-srbamcCMSH ;
Device = +pugsdr-intlbamcCMSH ;
Dynamic = +pinugtd-srlbamcCMSH ;
IgnoreAll = -pinugtsdrlbamcCMSH ;
IgnoreNone = +pinugtsdrbamcCMSH-l ;
ReadOnly = +pinugtsdbmCM-rlacSH ;
Temporary = +pugt ;

Первая строка задает маску параметров под названием Growing, с включением свойства pinugtdl и исключением srbamcCMSH.

Такая маска параметров подходит для постоянно растущих файлов (например, журналов) и примерно соответствует набору параметров Logs, рассмотренному нами в конфигурационном файле Aide.

Как и в Aide, файл политики Tripwire позволяет указать, какие маски параметров в каких участках файловой системы вы хотели бы применить – это и есть центральная часть конфигурации Tripwire. Вот несколько строк для примера:

/var/spool/mail -> $(Growing);
/bin -> $(ReadOnly) ;
/lib -> $(ReadOnly) ;
/sbin -> $(ReadOnly) ;
/tmp i -> $(Temporary);
!/proc; # Ignore this directory

Первая строка предписывает Tripwire проверять все файлы из директории /var/spool/mail по маске Growing, которую мы только что обсуждали. Последняя строчка иллюстрирует применение символа ! для исключения указанных директорий. В отличие от Aide, Tripwire не поддерживает регулярных выражений в именах файлов. Я привел здесь лишь некоторые общие правила, а при вдумчиво построенной политике безопасности подобный файл может состоять из сотен строк.

Отредактировав файл политики, надо зашифровать и подписать его. Снова запустите twadmin, например вот так:

twadmin -m P twpol.txt

Вам будет предложено ввести пароль сайта. Программа сгенерирует зашифрованный файл /etc/Tripwire/tw.pol.

Устройство ловушки

Необходимая подготовка проделана, и мы можем создавать исходную базу данных о файловой системе. Сделайте это с помощью # Tripwire --init. Процесс займет несколько минут; если в twpol.txt попадутся несуществующие директории, во время работы вы увидите предупреждения. Предположим, вы воспользовались конфигурационным файлом, рассмотренным выше. Снимок системы будет создан в /var/lib/Tripwire/hostname.twd (замените hostname реальным именем машины). В отличие от Aide, просмотреть этот файл непосредственно вы не сможете, он двоичный.

Рис. 4 Первая половина объемистого отчета Tripwire. Большинство отмеченных изменений вызвано добавлением учетной записи Barney.

ОК, пора начинать атаку! Для этого наш воображаемый недоброжелатель просто добавит новую учетную запись (а может быть, зарегистрированный пользователь создаст ее для своего бойфренда) командой # useradd barney. Для запуска Tripwire в режиме проверки наберите команду # Tripwire --check. Tripwire пошлет все данные об изменениях на стандартный вывод, а также в файл с названием вроде /var/lib/Tripwire/report/silas-20060915-152241.twr, где «silas» – название машины (да, я тоже читал «Код да Винчи»), а строка цифр – дата и время. Отчет весьма обширен и занимает два экрана (Рис. 4). Взглянув на второй экранный снимок, можно увидеть, что изменились файлы passwd, shadow и group (кроме прочих), к тому же была создана домашняя директория Barney (с несколькими файлами конфигурации). И снова этот клятый /etc/cups/cert/0…

Просмотрев отчет Tripwire, вы можете решить, что некоторые изменения вполне законны: например, Barney – желанный гость. Если это так, обновим базу данных командой:

# cd /var/lib/Tripwire/report
# Tripwire --update -r silas-20060915-152241.twr

Для вас запустится текстовый редактор (тот, что указан в строке EDITOR файла конфигурации Tripwire или в переменной окружения EDITOR), и в нем откроется отчет Tripwire. Отметьте одобренные изменения. Выйдите из редактора, и база данных обновится, Это предотвратит отметку одних и тех же изменений при каждой проверке.

Tripwire и Aide – не единственные инструменты обнаружения вторжений. Среди заслуживающих внимания я отметил бы Samhain, Osiris и Nabou. Чтобы ознакомиться с ними, посетите http://www.la-samhna.de/library/scanners.html.

Мысли напоследок

Итак, моя серия статей о безопасности подошла к концу. Быть может, вы видели впечатляющую пьесу театра Reduced Shakespeare Company под названием «Полное собрание сочинений Шекспира (Адаптировано)», где 27 сюжетов уместились в 97 минут. В подобной обработке (хотя и не столь артистично), для сообразительных и сильно занятых я привожу семь ключевых принципов, которые, надеюсь, вы усвоили в ходе наших занятий.

1. Применяйте сложные пароли, особенно для суперпользователя.
2. Избегайте прямого входа суперпользователя, когда им можно стать через su.
3. По возможности, не выдавайте пароль суперпользователя. При необходимости пользуйтесь sudo для контролируемого расширения прав доступа.
4. Отключите и/или удалите службы, которые вам не нужны.
5. Во время каждого обновления вашего дистрибутива убеждайтесь в том, что установлены новейшие доступные исправления безопасности.
6. Скрывайте компьютер за брандмауэром, а если не получается – создайте собственный фильтр пакетов для защиты машины.
7. Регулярно применяйте системы обнаружения вторжений типа Tripwire и Aide, и обязательно читайте их отчеты.

В этих принципах нет ничего сверхъестественного, но следование им существенно снизит риск для вашего компьютера. Желаю вам многолетней работы без взломов!