[Перевод] Kali Linux: мониторинг и логирование25.09.2017 15:48

→ Часть 1. Kali Linux: политика безопасности, защита компьютеров и сетевых служб
→ Часть 2. Kali Linux: фильтрация трафика с помощью netfilter

В предыдущих двух статьях из этой серии мы говорили о политике безопасности, о защите компьютеров и сетевых служб, о фильтрации трафика в Kali Linux. Благодарим наших читателей за полезные дополнения к этим материалам. В частности — пользователя imbasoft за ссылку на SANS Best Practices и за рекомендацию ознакомиться с комплексом стандартов СТО БР ИББС для погружения в тему бизнес-процессов управления безопасностью. Этот комментарий дан к первому материалу. Спасибо пользователю loginsin, который сделал ценные замечания ко второму материалу, касающиеся правил iptables и некоторых других тонкостей фильтрации трафика в Linux.

Сегодня мы хотим поделиться с вами переводом раздела 7.5. главы 7 книги «Kali Linux Revealed», который посвящён мониторингу и ведению журналов.

7.5. Мониторинг и логирование

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

Программы для мониторинга и логирования играют здесь ключевую роль, позволяя анализировать то, что происходит в системе и в сети.

В этом разделе мы рассмотрим некоторые инструменты, которые можно использовать для мониторинга Kali Linux.

7.5.1. Мониторинг журналов с использованием logcheck

Утилита logcheck предназначена для мониторинга лог-файлов, которые она, по умолчанию, ежечасно просматривает и отправляет необычные записи журналов на электронную почту администратора для дальнейшего анализа.

Список файлов, за которыми наблюдает программа, хранится в файле /etc/logcheck/logcheck.logfiles. Стандартные настройки позволяют logcheck нормально работать, при условии, если файл /etc/rsyslog.conf не был полностью изменён.

Logcheck поддерживает три уровня фильтрации: paranoid, server и workstation. Использование уровня paranoid приводит к тому, что logcheck отправляет администратору чрезвычайно длинные отчёты. Вероятно, его стоит использовать лишь на отдельных серверах, вроде тех, которые играют роль файрволов. Уровень server применяется по умолчанию, его рекомендовано использовать на большинстве серверов. Уровень workstation, что вполне очевидно из его названия, создан для рабочих станций, благодаря его использованию программа выдаёт краткие отчёты, отфильтровывая гораздо больше сообщений, чем при использовании других уровней фильтрации.

Во всех трёх случаях logcheck стоит настроить так, чтобы исключить из отчётов некоторые явно лишние сообщения (какие именно — зависит от служб, установленных в системе). Иначе приготовьтесь к тому, что каждый час вам будут приходить длинные неинтересные электронные письма. Механизм отбора сообщений для включения в отчёты довольно сложен, поэтому рекомендуется запастись терпением и осилить /usr/share/doc/logcheck-database/README.logcheck-database.gz.

Применяемые правила можно разделить на несколько типов:

Правила, которые анализируют сообщения на предмет поиска попыток взлома системы. Эти правила хранятся в файле, расположенном в директории /etc/logcheck/cracking.d/;
Правила для сообщений о попытках взлома, которые нужно игнорировать, описаны в /etc/logcheck/cracking.ignore.d/;
Правила для сообщений, оцениваемых как предупреждения безопасности, хранятся в /etc/logcheck/violations.d/;
Правила, для предупреждений безопасности, которые нужно игнорировать, хранятся в /etc/logcheck/violations.ignore.d/;
И, наконец, правила, которые применяются к остальным сообщениям (они рассматриваются как системные события).

Файлы ignore.d используются для игнорирования сообщений. Например, сообщение, помеченное как попытка взлома или предупреждение безопасности (в соответствии с правилом, хранящимся в файле /etc/logcheck/violations.d/myfile) может быть проигнорировано только при применении правила, которое хранится в файле /etc/logcheck/violations.ignore.d/myfile, или в файле /etc/logcheck/violations.ignore.d/myfile-extension.

Logcheck всегда сообщает о системных событиях, если только в директориях, схема именования которых показана ниже, не будет указано, что эти события нужно игнорировать:

/etc/logcheck/ignore.d.{paranoid,server,workstation}/

Естественно, во внимание принимаются только те директории, которые соответствуют уровню фильтрации, равному или превышающему выбранный.

7.5.2. Мониторинг в режиме реального времени

Программа top — это интерактивный инструмент, который выводит список выполняющихся процессов. Стандартная сортировка списка процессов основана на объёме потребляемых ресурсов процессора. При необходимости её можно активизировать с помощью ключа P. Другие способы сортировки процессов включают сортировку по занимаемому объёму оперативной памяти (ключ M), по общему времени использования процессора (ключ T), и по идентификатору процесса (ключ N). Ключ k позволяет завершить процесс, введя его идентификатор. Ключ r позволяет изменить приоритет процесса.

Если система выглядит перегруженной, top — это отличное средство, которое помогает узнать, какие процессы потребляют больше всего процессорного времени или занимают слишком много памяти. В частности, обычно полезно бывает проверить, соответствует ли потребление ресурсов процессами той роли, которую играет компьютер, тем службам, для поддержки которых он предназначен. Например, на неизвестный процесс, выполняющийся под пользователем «www-data», стоит обратить внимание. Его нужно исследовать, так как, возможно, это некая программа, установленная и запущенная в системе через уязвимость в веб-приложении.

Инструмент top весьма гибок, из его справки можно узнать подробности о том, как настроить выводимые им данные и приспособить его к вашим личным нуждам и предпочтениям.
Графическое средство gnome-system-monitor похоже на top, оно обладает примерно такими же возможностями.

7.5.3. Обнаружение изменений в системе

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

▍7.5.3.1. Аудит пакетов с помощью dpkg --verify

Команда dpkg --verify (или dpkg -V) — это интересный инструмент, который позволяет выводить сведения о системных файлах, которые были модифицированы (возможно — злоумышленниками), но вывод этой команды стоит рассматривать с долей скептицизма. Для того, чтобы сделать своё дело, утилита dpkg полагается на контрольные суммы, хранящиеся в её собственной базе данных на жёстком диске (её можно найти по пути /var/lib/dpkg/info/package.md5sums). Квалифицированный взломщик вполне может модифицировать эти файлы так, чтобы они содержали новые контрольные суммы для изменённых файлов. Если атакующий пойдёт ещё дальше — он подменит пакет на вашем зеркале Debian. Для того, чтобы защититься от подобных атак, используйте систему подтверждения цифровой подписи APT (подробнее об этом — в разделе 8.3.6. «Проверка подлинности пакета») для надёжной проверки пакетов.

▍Что такое контрольная сумма файла?

Хотим напомнить о том, что контрольная сумма — это значение, часто являющееся числом (хотя и в шестнадцатеричной записи), которое содержит нечто вроде сигнатуры для содержимого файла. Сигнатура вычисляется с помощью некоего алгоритма (среди них — широко известные MD5 и SHA1), которые, в целом, гарантируют, что даже мельчайшее изменение в файле приведёт к изменению контрольной суммы. Это явление известно как «эффект лавины». Простая цифровая сигнатура затем служит средством для проверки того, изменилось ли содержимое файла. Эти алгоритмы не поддаются обратному преобразованию. Другими словами, для большинства из них, знание сигнатуры не позволяет восстановить данные, на основе которых эта сигнатура создана. Последние исследования в области математики ставят под вопрос абсолютность этого принципа, но до сих пор на практике подобное не используется, так как создание различных наборов данных, имеющих одинаковую контрольную сумму всё ещё остаётся весьма сложной задачей.

Выполнение команды dpkg -V приведёт к проверке всех установленных пакетов и выводу сведений о тех из них, которые проверку не прошли. Каждый символ в строке сведений о пакете указывает на проверку некоторых метаданных. К сожалению, dpkg не хранит метаданные, необходимые для большинства тестов, и, таким образом, выводит для них знаки вопроса. В настоящее время только если пакет не проходит испытание контрольной суммой, на третьей позиции появляется цифра 5.

# dpkg -V
??5??????   /lib/systemd/system/ssh.service
??5?????? c /etc/libvirt/qemu/networks/default.xml
??5?????? c /etc/lvm/lvm.conf
??5?????? c /etc/salt/roster

В этом примере dpkg сообщает об изменении в файле ssh.service, которое сделал администратор, вместо того, чтобы использовать переопределение правил для /etc/systemd/system/ssh.service, (которое сохранилось бы в директории /etc, где и должны храниться файлы, задающие изменения конфигурации). Кроме того, команда выводит несколько конфигурационных файлов (для таких файлов во второй колонке отчёта выводится буква «c»), которые были модифицированы вполне обоснованно.

▍7.5.3.2. Мониторинг файлов: AIDE

Средство Advanced Intrusion Detection Environment (AIDE) позволяет проверять целостность файлов и обнаруживает любые изменения в сравнении с ранее сохранённым образом правильно сконфигурированной системы. Образ хранится в виде базы данных (/var/lib/aide/aide.db) и содержит соответствующие данные (контрольные суммы, разрешения, отметки времени) обо всех файлах системы.

Установить AIDE можно так:

apt update
apt install aide

После установки нужно инициализировать базу данных командой aideinit. Эта операция затем будет выполняться ежедневно (с помощью скрипта /etc/cron.daily/aide) для проверки того, что системные файлы не изменились. В случае обнаружения изменений, AIDE записывает их в лог-файлы (/var/log/aide/*.log) и отправляет отчёт администратору по электронной почте.

▍Защита базы данных AIDE

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

Для настройки пакета aide можно воспользоваться параметрами в /etc/default/aide. А именно, внутренние настройки программы хранятся в файлах /etc/aide/aide.conf и /etc/aide/aide.conf.d/ (на самом деле, это — единственные файлы, используемые update-aide.conf для формирования /var/lib/aide/aide.conf.autogenerated). Конфигурация указывает на то, какие свойства каких файлов должны быть проверены. Например, состояние файлов журналов постоянно меняется, подобные изменения можно игнорировать, до тех пор, пока разрешения, заданные для этих файлов не меняются. Однако, в случае с исполняемыми файлами, и их содержимое, и разрешения, должны оставаться неизменными. Хотя эти настройки не так уж и сложны, синтаксис конфигурационных файлов AIDE нельзя назвать полностью интуитивно понятным, поэтому тем, кто хочет разобраться с настройкой AIDE, рекомендуем почитать manaide.conf(5).

Новая версия базы данных создаётся ежедневно по адресу /var/lib/aide/aide.db.new. Если все зафиксированные изменения допустимы, ей можно заменить эталонную базу данных.

Инструмент Tripwire очень похож на AIDE. Даже синтаксис конфигурационных файлов практически тот же самый. Главное улучшение, которое даёт tripwire, заключается в механизме подписывания конфигурационного файла, в результате чего атакующий не может изменить его так, чтобы он указывал на другую версию эталонной базы данных.

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

▍Пакеты checksecurity и chkrootkit/rkhunter

Пакет checksecurity представляет собой набор небольших скриптов, которые выполняют основные проверки системы (поиск пустых паролей, новых файлов setuid, и так далее) и выдают предупреждения, если удаётся найти что-то подозрительное. Название пакета, checksecurity, может создать у администратора впечатление о том, что проверив систему с помощью этого пакета можно гарантировать её защищённость. Однако, не стоит всецело полагаться на этот пакет.
Пакеты chkrootkit и rkhunter предназначены для обнаружения конкретных руткитов, которые могут быть установлены в системе. Руткиты — это программы, которые созданы для того, чтобы не привлекая внимания администратора, незаметно использовать компьютер. Испытания, которые выполняют вышеупомянутые пакеты, нельзя назвать на 100% надёжными, но обычно если они что-то находят — на это стоит обратить внимание.

Итоги

Сегодня мы поговорили о мониторинге и логировании в Kali Linux. Рассмотренные здесь инструменты позволяют поддерживать уровень защиты системы и её работоспособность в хорошем состоянии, однако, всегда стоит помнить о том, что у атакующих есть средства противодействия многим системам контроля. В следующем материале мы подведём итоги 7-й главы и предложим вам несколько упражнений, которые позволят вам проверить свои знания и узнать что-то новое о Kali Linux.

Уважаемые читатели! Как вы организуете мониторинг ваших Linux-систем?