Наши партнеры

UnixForum





Библиотека сайта rus-linux.net

Ошибка базы данных: Table 'a111530_forumnew.rlf1_users' doesn't exist

Узловые системы обнаружения вторжений

Оригинал: Host-Based IDS
Автор: Tobias Eggendorfer
Дата публикации: 1 февраля 2016 г.
Перевод: А.Панин
Дата перевода: 20 марта 2017 г.

Узловая система обнаружения вторжений является простым, но очень мощным инструментом для обнаружения признаков деятельности злоумышленников.

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

IT-профессионалы используют множество различных инструментов для защиты современных сетей, начиная от межсетевых экранов и заканчивая сложными фреймворками для предотвращения вторжений. (Обратитесь к разделу "NIDS, IPS, HIDS".) Одним из полезных классов таких фреймворков являются узловые системы обнаружения вторжений (Host-based Intrusion Detection System - IDS). Эти системы осуществляют проверки на отдельных узлах с целью выявления признаков недавних атак.

NIDS, IPS, HIDS

В результате включения сирены жильцы дома узнают о том, что к ним в дом проник грабитель. В мире компьютеров сетевая система обнаружения вторжений (Network-based Intrusion System - NIDS) тихо сохраняет информацию о происшествии и помогает системному администратору отследить или перехватить злоумышленника.

Связанный инструмент под названием "система предотвращения вторжений" (Intrusion Prevention System - IPS) автоматически поднимает мост перед тем, как предполагаемый злоумышленник начнет пересекать ров с водой; например, это делается путем изменения правил межсетевого экрана либо для блокировки входа, либо для перенаправления злоумышленника в ловушку, где он может бесконечно искать интересующую его информацию. Администраторы могут изучать действия злоумышленников и использовать полученные знания для улучшения защиты своих систем.

Исследование разграбленных шкафов для бумаг и разломанных рам является не самым оперативным способом обнаружения вторжений, но это именно тот подход, который используется в узловых системах обнаружения вторжений (Host-based Intrusion Detection Systems - HIDS). Так как опаздывающие люди зачастую пропускают самые важные события в своей жизни, узловые системы обнаружения вторжений не пользуются особой популярностью в современных сетях. Но данное отношение формируется без учета того факта, что взломщики компьютерных систем обычно оставляют хотя бы минимальное количество следов своей деятельности. Без узловой системы обнаружения вторжений жертва может вообще не предполагать о наличии незваных гостей. Простой инструмент для поиска информации об изменениях состояния системы злоумышленниками с возможностью вывода информации о местах поиска вредоносного программного обеспечения может очень помочь в процессе аудита безопасности системы.

Узловые системы обнаружения вторжений используют принцип, в соответствии с которым каждый злоумышленник оставляет следы своей деятельности. В экспертных науках данный принцип известен как принцип обмена Локарда: взаимодействие всегда приводит к изменению состояния. Задачей рассматриваемых систем является идентификация данного изменения состояния и формирование корректных выводов на его основе [1].

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

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

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

Изменения файловой системы

Злоумышленник получает особое наслаждение от вторжения в систему путем эксплуатации уязвимости переполнения буфера. Но после того, как он оказывается в системе, его работа становится более монотонной. Обычно он начинает вторжение с установки руткита для ввода в строй удобного механизма входа в систему. В процессе установки руткита злоумышленник обычно загружает в систему определенный исполняемый файл и исполняет его, причем системный администратор сможет заметить соответствующий процесс, воспользовавшись командой ps. Для успешного использования бэкдора, позволяющего управлять удаленной системой, злоумышленнику придется организовать прием соединений на определенном порту, причем этот открытый порт в большинстве случаев будет отображаться при использовании утилиты netstat. Обычно злоумышленникам приходится предпринимать дополнительные меры для того, чтобы установленное ими программное обеспечение не было видимо для стандартных инструментов администрирования системы. Чаще всего в подобных случаях осуществляется подмена исполняемых файлов стандартных утилит для администрирования системы, таких, как ps и netstat на их специальные версии, скрывающие наличие вредоносного программного обеспечения. Используются и более современные подходы, связанные с использованием руткитов для ядра ОС, а также с установкой модулей ядра ОС, скрывающих процессы руткитов на его уровне.

Системные администраторы могут идентифицировать подмененные злоумышленниками бинарные файлы стандартных инструментов Linux на основе отличающихся меток времени их создания и модификации, отличающихся размеров, а также использования этими бинарными файлами отличных структур inode. На практике системные администраторы, не использующие какие-либо автоматизированные инструменты для защиты систем, никогда не обнаружат таких подмен, так как соответствующие проверки в ручном режиме занимают слишком много времени. Классические узловые системы обнаружения вторжений, такие, как Tripware [2], AIDE [3] или новая система AFICK [4] предоставляют механизмы для обнаружения подобных изменений файловой системы, работающие в автоматическом режиме.

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

Конечно же, опытные злоумышленники, скорее всего, соберут свое вредоносное программное обеспечение таким образом, чтобы размер результирующего бинарного файла совпал с размером оригинального файла подменяемой утилиты; они также смогут установить идентичные метки времени с помощью утилиты touch, сохранить оригинальные права доступа к файлу и разместить модифицированную версию файла в области файловой системы, связанной с той же структурой inode (с помощью команды cat newps > ps). Однако, специально для таких случаев узловые системы обнаружения вторжений хранят не только параметры исполняемых файлов, но и их контрольные суммы.

AIDE позволяет даже рассчитывать контрольную сумму бинарных файлов с помощью нескольких различных хэш-функций в параллельном режиме, что делает коллизии еще менее вероятными: в случае хэш-функции MD5 сложность поиска коллизии имеет порядок менее 264, а в случае SHA-256 - менее 2128. В случае же применения двух упомянутых хэш-функций одновременно сложность поиска коллизии будет иметь порядок менее 2192, то есть примерно 1.5/1058. Для сравнения стоит сказать, что если вы играете в лотерею, ваши шансы на выигрыш равны 7/109.

AIDE является отличным примером узловой системы обнаружения вторжений, которая отслеживает изменения файлов. В основанных на Debian дистрибутивах для установки AIDE может использоваться команда:

apt-get install aide

Вы можете отредактировать файл конфигурации данного инструмента в соответствии со своими потребностями. Для изменения глобальной конфигурации рассматриваемого инструмента вам придется отредактировать файл /etc/aide/aide.conf, а для внесения специальных правок - создать файл конфигурации с необходимыми директивами в директории /etc/aide/aido.conf.d. Главной целью редактирования файла конфигурации является внесение модификаций, благодаря которым AIDE будет отслеживать состояние важных программ и файлов конфигурации.

Файл конфигурации aide.conf также может содержать пользовательские макросы. Изучение макросов поможет вам сэкономить достаточно много времени в процессе создания правил. AIDE автоматически обнаруживает создаваемые файлы, к примеру, в результате сохранения дампов памяти приложений, которые нередко создаются в результате наличия ошибок переполнения буфера в приложениях. (Функция создания дампов памяти приложений отключена по умолчанию в большинстве современных дистрибутивов Linux [5].)

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

В AIDE для обновления конфигурации используется инструмент update-aide.conf; также вы можете использовать команду aide -D для проверки синтаксиса файлов конфигурации. Команда

aideinit -y -f

предназначена для инициализации базы данных. Далее AIDE будет осуществлять расчет контрольных сумм файлов - этот процесс занимает около 10 минут на системе в виртуальной машине, установленной на моем компьютере. Ввиду того, что вместе с установкой AIDE в систему автоматически устанавливается файл задачи cron, впоследствии данный инструмент будет автоматически искать изменения важных файлов и отправлять сообщения с отчетами пользователю root по электронной почте. AIDE также может отправлять отчеты на веб-ресурс по адресу в форме строки URL (задается с помощью директивы report_url файла конфигурации aide.conf), что позволяет организовать сбор отчетов на отдельном централизованном ресурсе.

AIDE отлично эмулирует поведение других аналогичных инструментов, благодаря чему вы можете без каких-либо сложностей использовать правила, созданные в процессе работы с таким инструментом, как Tripware.

Журналы, журналы, журналы

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

Инструмент Logsentry [6] (ранее имевший название Logcheck) оказывается крайне полезным при возникновении необходимости в анализе содержимого системных журналов: это простая, но при этом полноценная узловая система обнаружения вторжений, состоящая исключительно из сценариев командной оболочки и файлов конфигурации. Logsentry избавляет системных администраторов от необходимости подбора корректных команд фильтрации на основе утилиты grep с целью выявления следов атак на основе содержимого системных журналов. Вам придется загрузить архив с компонентами Logsentry и установить эти компоненты в систему с помощью следующей последовательности команд:

tar -xzf logcheck-1.3.17.tar.gz
cd logcheck-1.3.17
make linux

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

crontab -e

в результате чего в текстовом редакторе откроется файл конфигурации crontab. Вам придется добавить в него строку

0 * * * * /usr/local/etc/logcheck.sh

которая предназначена для запуска сценария logcheck.sh каждый час. Если вы хотите исследовать более трех файлов журналов, имена которых заданы по умолчанию, вам придется отредактировать файл logcheck.sh, добавив в него имена всех интересующих вас файлов журналов начиная со строки 172, причем вы можете использовать расположенные выше строки в качестве примеров. Правила Logcheck расположены во множестве файлов конфигурации из директории /etc/logcheck.

Все записи, описанные в файле конфигурации logcheck.hacking, будут появляться в самом начале сообщения электронной почты, отправляемого пользователю root. Записи, описанные в файле конфигурации logcheck.violations будут находиться в этом же сообщении ниже. Все записи, которые не исключены из рассмотрения с помощью файла конфигурации ignore, будут добавляться в сообщение, включая необычные системные события (Unusual system events). Крайне важно убедиться в том, что вы не оставили файл конфигурации logcheck.ignore пустым - это эквивалентно шаблону для игнорирования всех событий, который делает инструмент бесполезным.

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

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

Поиск вредоносного программного обеспечения

Если в результате анализа системных журналов и проверок файлов выясняется, что в систему все же было осуществлено вторжение, имеет смысл проверить систему на наличие в ней вредоносного кода. Эта работа осуществляется сканерами вредоносного программного обеспечения, существующими также и в Linux. ClamAV [7] является примером такого сканера. Разделение между сканерами вредоносного программного обеспечения и узловыми системами обнаружения вторжений является вполне очевидным; большая часть антивирусов использует как сигнатуры, так и эвристический анализ для идентификации атак.

Такие программы, как Chrootkit [8] и RKHunter [9] (инструмент, разработанный с использованием языка программирования Perl) используют более четкий подход; оба этих инструмента в последний раз обновлялись в 2014 году, поэтому вы можете установить их новейшие версии в Ubuntu, выполнив от лица пользователя root следующие команды:

apt-get install chkrootkit
apt-get install rkhunter

Chrootkit является сценарием командной оболочки, который пытается идентифицировать руткиты на основе различных параметров. Вы можете запустить Chrootkit без передачи каких-либо параметров. Помимо прочего, сценарий Chrootkit использует утилиту strings для выявления подозрительных строк в бинарных файлах, утилиту lastlog для выявления фактов удаления записей, соответствующих входам в систему, а также утилиту ps для выявления неотображаемых процессов и информации, отсутствующей в виртуальной файловой системе /proc/ (Рисунок 1).

Chrootkit предпринимает попытки обнаружения типичных признаков функционирования руткитов

Рисунок 1: Chrootkit предпринимает попытки обнаружения типичных признаков функционирования руткитов.

RKHunter использует более сложный подход. Конфигурационный файл данного инструмента расположен по пути /etc/rkhunter.conf. (Я столкнулся с некоторыми проблемами при настройке RKHunter в Ubuntu - в расположенном ниже разделе "Исправления для Ubuntu" описана методика их устранения.)

Исправления для Ubuntu

Мне пришлось провести некоторое исследование проблем, возникающих после установки RKHunter в Ubuntu. Для корректной работы программы требовалось установить программный компонент lwp-request, который не устанавливался автоматически. Я попытался решить эту проблему с помощью следующей команды:

cpan Mock::LWP::Request

Однако, инструментарий Perl установил данный программный компонент по пути /usr/local/bin/lwp-request, что было сюрпризом для RKHunter - это обозначает, что вам придется самостоятельно заменить соответствующий путь к директории /usr/bin в файле конфигурации рассматриваемой программы.

Вы можете инициализировать RKHunter и проверить систему на наличие руткитов и подозрительных файлов с помощью следующей последовательности команд:

rkhunter --propupd
rkhunter --check

На Рисунке 2 показан пример выявления RKHunter потенциальных векторов атаки на систему. Вы можете вызывать Chrootkit и RKHunter ежедневно из задачи cron, сделав тем самым эти инструменты частью вашей узловой системы обнаружения вторжений.

Одной из задач RKHunter является проверка наличия в системе подозрительных файлов

Рисунок 2: Одной из задач RKHunter является проверка наличия в системе подозрительных файлов.

Все в одном

Вместо трех дополняющих друг друга инструментов могут использоваться комплексные решения, реализующие все описанные функции. Использовать их или нет - зависит от ваших предпочтений. Известными комплексными решениями являются Samhain [10] и OSSEC [11]. Оба этих инструмента работают на удаленных системах в режиме агента, проводя исследования и отправляя их результаты на центральный компьютер для последующей обработки.

Если вы страдаете паранойей и имеете достаточно свободного времени для чтения всех сообщений электронной почты, вас обрадует информация о том, что при одновременном запуске нескольких узловых систем обнаружения вторжений эти системы не будут конфликтовать друг с другом. Другими словами, вы можете запустить комбинацию из таких инструментов, как Tripware, AIDE, AFICK, Samhain и OSSEC на одном компьютере и позволить каждому из этих инструментов осуществлять мониторинг работы системы и всех других инструментов. Стоит предупредить вас и о том, что в случае их одновременного обновления система может зависнуть, поэтому не стоит увлекаться.

Рекомендую обратиться к опубликованным в Интернет руководствам по работе с Samhain [12] и OSSEC [13]. Для использования этих инструментов не нужно обладать особыми знаниями; достаточно просто понимать принцип работы их компонентов.

В дополнение следует сказать, что каждая дополнительная строка кода потенциально содержит критические ошибки. Например, в OSSEC с версии 2.7 по версию 2.8.1 содержалась ошибка, позволяющая повысить привилегии в системе, которая была обнаружена в июне 2015 года: CVE-2015-3222 [14]. В состав версии 2.8.2 было включено исправление этой ошибки. Вне зависимости от используемого для защиты сети инструментария, в комплекс мер по обслуживанию узловой системы обнаружения вторжений должно входить отслеживание выпускаемых обновлений безопасности: вам ведь наверняка не хочется, чтобы злоумышленники использовали найденные в ней уязвимости для вторжения в вашу систему.

Поиск злоумышленника

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

Многие подобные инструменты теряют свою актуальность тогда, когда злоумышленник получает привилегии пользователя root и обладает временем, достаточным для отключения механизмов защиты и сокрытия следов пребывания в системе. Так как по своей природе узловые системы обнаружения вторжений могут лишь исследовать результаты попыток осуществления атак, они могут выступать лишь в качестве одного из строительных блоков систем безопасности. Сетевая система обнаружения вторжений, межсетевые экраны, ограничения прав пользователей, регулярные аудиты безопасности систем и мероприятия по ознакомлению пользователей с аспектами безопасной работы с компьютером дополняют пазл.

Источники дополнительной информации

  1. Принцип Локкарда: https://en.wikipedia.org/wiki/Locard%27s_exchange_principle
  2. Tripwire: http://sourceforge.net/projects/tripwire/
  3. AIDE: http://aide.sourceforge.net
  4. AFICK: http://afick.sourceforge.net
  5. Активация функции создания дампов памяти приложений: http://en.linuxreviews.org/HOWTO_enable_core-dumps
  6. Logsentry: http://sourceforge.net/projects/sentrytools/files/logcheck%201.x/logcheck-1.1.1/
  7. ClamAV: http://www.clamav.net/index.html
  8. Chkrootkit: http://www.chkrootkit.org
  9. RKHunter: http://rkhunter.sourceforge.net
  10. Samhain: http://www.la-samhna.de/samhain/
  11. OSSEC: http://www.ossec.net
  12. Руководство по использованию Samhain: http://www.la-samhna.de/samhain/MANUAL-2_4.pdf
  13. Руководство по использованию OSSEC: http://ossec-docs.readthedocs.org/en/latest/manual/installation/index.html
  14. CVE-2015-3222: http://www.openwall.com/lists/oss-security/2015/06/11/1



Средняя оценка 5 при 1 голосовавших

Комментарии