Книга: Сетевые средства Linux

Инструменты, выявляющие попытки вторжения

Инструменты, выявляющие попытки вторжения

Если взломщик проникает в систему, он изменяет ее конфигурацию в соответствии со своими потребностями. В зависимости от характера вторжения изменяется внешний вид Web-страниц, в файлах протоколов появляются новые записи, упрощающие обращение злоумышленников к системе, изменяются коды программ, а также появляются другие "сюрпризы". К сожалению, предсказать, какие именно действия предпримет взломщик, невозможно. Именно поэтому бороться с последствиями вторжения крайне сложно; если вы не знаете, что предпринял взломщик и каковы были его цели, нельзя доверять ни одной из системных программ. Радикальное решение — удалить с дисков компьютера всю информацию и повторно установить систему или восстановить ее с помощью резервной копии, сделанной еще до атаки.

Поскольку взломщик модифицирует системные файлы, наличие измененных файлов может служить признаком атаки. Обнаружить факт проникновения в систему можно лишь в том случае, если администратор заранее сохранил информацию о состоянии основных системных файлов, например, файла /etc/passwd и исполняемых программ в каталоге /bin. Эта информация должна храниться в закодированном виде либо ее следует записать на сменный носитель. Эти данные необходимо периодически использовать для проверки целостности файлов. Если файл, который не должен был подвергаться изменениям, окажется модифицированным, есть все основания полагать, что система была взломана. (Необходимо учитывать, что некоторые файлы мог изменить сам администратор. Например, при создании новой учетной записи данные записываются в файл /etc/passwd.)

Использование базы данных пакетов

Во многих версиях Linux есть инструмент, который можно использовать для контроля целостности файлов. Речь идет о базе данных пакетов. Система управления пакетами Debian и система RPM сохраняют в базе данных информацию об инсталлированных программах. Для сравнения программы на диске с исходным содержимым пакета надо указать опцию --verify (или -V) программы rpm. Ниже приведен пример вызова данной команды.

# rpm -V postfix
S.5.... Т с /etc/postfix/aliases
S.5.... Т с /etc/postfix/main.cf

В результате выполнения программы выводится информация о файлах, состояние которых не соответствует исходному. В начале каждой строки выходных данных содержится набор признаков, сообщающих о характере несоответствия файлов. Например, буква "S" указывает на то, что размер файла изменился, цифра "5" свидетельствует о несоответствии сумм MD5, а буква "Т" означает; что изменилось время модификации файла. Сообщения, отображаемые в данном примере, не являются признаком атаки, так как файлы, указанные программой, могут периодически изменяться при настройке пакета. Если же вы выясните, например, что был изменен исполняемый файл Postfix, вам необходимо начать поиски других признаков вторжения, а впоследствии предпринять меры для устранения последствий атаки.

В системе Debian аналогичные функции выполняет утилита dlocate, однако она не входит в составе Debian 2.2. Установив данную программу, вы сможете выполнить команду наподобие следующей:

# dlocate -md5check postfix

При выполнении данной команды проверяются суммы MD5 для содержимого пакета postfix и генерируется отчет о том, совпадают ли эти суммы для каждого файла.

Вместо проверки каждой программы вы можете проверить целостность всех пакетов, используя команду rpm -Va. Выходные данные будут насчитывать сотни строк, большинство из которых сообщают об изменениях конфигурационных файлов и файлов данных. Такие сообщения можно не принимать во внимание. Учитывая большой объем данных, желательно перенаправить выход в файл либо передать сгенерированную программой информацию утилите more или less.

Программы rpm и dlocate имеют существенные недостатки. Один из них состоит в том, что после инсталляции пакета нельзя выяснить, кто внес изменения в конфигурационный файл: системный администратор или взломщик. Кроме того, при желании взломщик может легко скрыть следы своего вмешательства. Для этого ему надо лишь использовать для установки модифицированных программ диспетчер пакетов. Например, если злоумышленник хочет заменить оболочку /bin/bash, ему достаточно установить новый RPM-пакет bash. В результате вызов rpm -Va не выявит изменений. По этой причине не следует полностью полагаться на диспетчер пакетов; желательно использовать наряду с ним дополнительные инструменты, предназначенные для выявления вмешательства в работу системы. Общее правило можно сформулировать так. Если диспетчер пакетов обнаружил изменения файлов, полученное сообщение следует рассматривать как признак того, что система подверглась атаке. Если же диспетчер пакетов не смог выявить изменения, этот факт не может быть гарантией целостности системы.

Использование Tripwire

Для выявления случаев несанкционированного доступа к системе разработан инструмент Tripwire (http://www.tripwire.org). Эта программа поставляется со многими версиями Linux. Если же в вашем дистрибутивном пакете она отсутствует, скопируйте ее с Web-узла. Версию Tripwire, входящую в состав дистрибутивного пакета, инсталлировать гораздо проще, чем пакет, скопированный с Web-узла, так как в ней заранее учтены набор файлов, используемых в системы, и их расположение. Tripwire сохраняет информацию о файлах в базе данных, этим данный инструмент напоминает диспетчеры пакетов, однако в нем реализованы специальные функции, превращающие его в специализированное средство обеспечения защиты. Tripwire может быть сконфигурирован для хранения информации о произвольном наборе файлов, причем сведения о файлах записываются в базу данных после инсталляции. Вы можете создать базу данных после того, как внесете необходимые изменения в конфигурационные файлы. В процессе работы Tripwire шифрует информацию, что не дает возможности взломщику изменить базу данных. Для обеспечения сохранности базы Tripwire поместите ее на сменный носитель, запретив запись данных.

Tripwire может работать в одном из следующих режимов.

• Генерация базы данных. При первом запуске Tripwire необходимо инициализировать базу данных. Для этого после редактирования конфигурационного файла вызовите команду tripwire -initialize. Выполнение этой процедуры может продлиться достаточно долго, так как программа Tripwire должна создать контрольные суммы всех файлов, контроль над которыми был предусмотрен при настройке данного инструмента. Сформированная база данных помещается в подкаталог databases текущего каталога, но желательно переместить ее в каталог /usr/lib/tripwire/databases. Запись данных в этот каталог следует запретить.

• Обновление базы данных. Если вы внесли изменения в систему, можете обновить базу данных Tripwire. Для этого вызовите команду tripwire -update путь_к_файлу, указав файл, который необходимо учесть в базе данных.

• Интерактивное обновление базы данных. Если внесенные вами изменения затрагивают несколько компонентов системы или если вы установили большой пакет, запустите Tripwire в интерактивном режиме. Для этого вызовите команду tripwire -interactive. В этом случае программа будет отыскивать файлы, подвергшиеся изменениям, и осведомляться у вас, следует ли учитывать эти изменения в базе данных.

• Проверка целостности системы. Этот режим используется по умолчанию. Для того чтобы запустить Tripwire в таком режиме, достаточно ввести в командной строке tripwire. Проверку целостности системы желательно выполнять каждый день. Периодический вызов Tripwire можно организовать с помощью cron.

Работой Tripwire управляет конфигурационный файл /etc/tripwire/tw.config. Подобно многим другим конфигурационным файлам, строки, начинающиеся с символа #, содержат комментарии. В остальных строках указываются каталоги, предназначенные для проверки. Соответствующие записи имеют следующий формат:

[!|=] объект [флаги_выбора | шаблон]

Назначение компонентов записи приведено ниже.

• !. Если данный символ предшествует имени объекта, то указанный файл или каталог не подлежит проверке. Если объектом является каталог, содержащиеся в нем подкаталоги также не проверяются.

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

• объект. Объект представляет собой имя файла или каталога, предназначенного для проверки, например /etc или /usr. Если в качестве объекта указан каталог, выполняется проверка всех его подкаталогов. Не проверяются лишь подкаталоги, представляющие собой отдельные файловые системы. Например, если содержимое каталогов /usr и /usr/local находится в разных разделах, то, чтобы проверить все дерева подкаталогов, вы должны создать записи как для /usr, так и для /usr/local.

• флаги_выбора. Данный компонент записи указывает Tripwire на то, какие типы изменений должны быть отражены в отчете. Флаги задаются в формате [+|-] [pinugsamc123456789]... . Символ + или - разрешает или запрещает включать сведения в отчет. Остальные символы определяют типы проверки. Например, p задает поверку прав доступа, i — проверку индексных дескрипторов (mode), n соответствует числу связей, u — идентификатору владельца файла, g — идентификатору группы, s — размеру файла, а — времени доступа, m — времени модификации, с — времени создания индексного дескриптора, а числа 0-9 задают особенности контрольного суммирования.

• шаблон. Вместо флагов выбора вы можете задать шаблон. По умолчанию принимается шаблон R, соответствующий +pinugsm12-ac3456789. В качестве примеров других шаблонов можно привести L(+pinugsacm123456789), используемый для проверки файлов протоколов, N (+pinugsamc123456789), который выполняет подробную проверку, но проверка эта занимает много времени, и E(-pinugsamc123456789), игнорирующий все типы проверки.

Сформировав конфигурационный файл Tripwire, вы должны запустить программу в режиме генерации базы данных. В результате файл базы данных будет создан в каталоге databases. При последующих запусках Tripwire будет отыскивать файл базы данных в каталоге /usr/lib/tripwire/databases. Этот файл очень важен, поэтому вы должны обеспечить его сохранность. Способы сохранения файла базы данных описаны ниже.

• Файл базы данных может храниться на сменном носителе, защищенном от записи, например на дискете или компакт-диске. Если вы собираетесь выполнять проверку, периодически запуская Tripwire с помощью cron, носитель может быть постоянно смонтирован (такой подход создает неудобства при работе с системой). Если вы предполагаете запускать Tripwire вручную, носитель можно монтировать непосредственно перед проверкой.

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

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

• Tripwire поддерживает кодирование данных, поэтому файл базы данных можно сохранить в зашифрованном виде. Чтобы изменить содержимое файла базы данных, взломщик должен знать пароль, использовавшийся при кодировании.

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

Оглавление книги


Генерация: 1.401. Запросов К БД/Cache: 3 / 1
поделиться
Вверх Вниз