Жесткая закалка Linux. Подбираем инструменты для комплексного аудита безопасности

В этом материале мы познакомимся с основными утилитами для Linux hardening. На русском языке это называется как-то вроде «проверка уровня защищенности Linux-систем и оценка корректности конфигов с точки зрения ИБ». Разумеется, мы не только сделаем обзор программ, но и приведем примеры их использования.

Сам себе аудитор, или безопасность собственными силами

Перед администраторами, а уж тем более перед аудиторами ИБ часто встают задачи проверить защищенность большого количества хостов за очень короткое время. И конечно, для решения этих задач в Enterprise-сегменте существуют специализированные инструменты, к примеру такие, как сетевые сканеры безопасности. Уверен, что все они — от open sources движка OpenVAS до коммерческих продуктов типа Nessus или Nexpose — известны нашему читателю. Однако этот софт обычно используется, чтобы искать устаревшее и потому уязвимое ПО и затем запустить патч-менеджмент. К тому же не все сканеры учитывают некоторые специфические особенности встроенных механизмов защиты Linux и других open sources продуктов. Ну и не в последнюю очередь значение имеет цена вопроса, ведь коммерческие продукты в состоянии позволить себе разве что компании, выделяющие под это дело бюджеты.

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

Практические аспекты аудита защищенности

Если посмотреть глазами аудитора, то подход к тестированию можно разделить на два типа.

Первый — это соответствие так называемым compliance-требованиям, здесь проверяется наличие обязательных элементов защиты, прописанных в каком-либо международном стандарте или «best practice». Классический пример — требования PCI DSS для платежных ИТ-систем, SOX404, NIST-800 series, MITRE.

Второй — это сугубо рациональный подход, основанный на вопросе «А что еще можно сделать, чтобы усилить защищенность?». Тут нет обязательных требований — только твои знания, светлая голова и умелые руки. К примеру, это обновление версии ядра и/или пакетов приложений, включение шифрования томов, форсирование SELinux, настройка файрвола iptables.

Все, что относится ко второму подходу, принято называть специальным термином Hardening, что еще можно определить как «действия, направленные на усиление уровня исходной защищенности операционной системы (или программы) преимущественно штатными средствами».

Соответствие compliance-требованиям, как правило, проверяют при подготовке к прохождению обязательного аудита типа PCI DSS или другого сертификационного аудита. Мы же больше уделим внимание Hardening-составляющей. Все крупные разработчики предлагают для своих продуктов Hardening Guidelines — руководства, содержащие советы и рекомендации, как усилить защищенность, учитывая штатные механизмы безопасности и специфику софта. Так, подобные руководства есть у Red Hat, Debian, Oracle, Cisco.

INFO

Hardening — это термин из мира ИБ, который обозначает процесс обеспечения безопасности системы (программы) за счет снижения ее уязвимости и, как правило, с использованием только штатных утилит или механизмов защиты.

Кстати, на Хакере уже была схожая статья про настройку опций Hardening, но тогда речь шла именно о настройке. Мы же сначала почекаем нашу систему с помощью специальных утилит, то есть проведем аудит ИБ, оценим текущий уровень защиты, а потом уже накрутим туда security option, если необходимо. Ну или еще как вариант: если сервер уже оттюнингован с точки зрения безопасности, наши тулзы смогут это проверить и, возможно, подсказать, что же можно сделать еще.

Обзор инструментов

1. Lynis — auditing, system hardening, compliance testing

Lynis — первая в нашем списке инструментов и, пожалуй, самая навороченная тулза для аудита Linux-систем. При этом она очень простая в использовании и очень наглядная — все тесты и их результаты выводятся на экран. Утилита сканирует настройки текущего уровня безопасности и определяет состояние защищенности (hardening state) машины. Найденные тревожные сигналы и важные алерты безопасности выводятся в консоль терминала и отдельно в лог-файл, сгруппированные по блокам. Кроме сведений о безопасности, Lynis также поможет получить общесистемную информацию, информацию об установленных пакетах и возможных ошибках конфигурации, обновлениях ядра.

Разработчиками заявлена поддержка огромного числа операционных систем: от Arch, BackTrack, Kali до разновидностей Debian/Ubuntu, RHEL/CentOS, SuSE, BSD-семейства (FreeBSD, NetBSD, OpenBSD, DragonFly BSD), а также более экзотичных HPUX, Solaris 10+, TrueOS и macOS.

Вся документация с более подробным описанием и примерами использования доступна в разделе Lynis Documentation на официальном сайте CISOfy. Если не хочешь ограничиваться предлагаемыми тестами, есть возможность разработки собственных. Более подробно об этом написано в разделе Lynis Software Development Kit. Ну и для тех, кто еще сомневается, устанавливать или нет утилиту, разработчики подготовили небольшое demo, поясняющее, как происходит установка и первичный запуск.

Кроме бесплатной версии, которую мы и будем чуть ниже использовать, разработчики предлагают решение Enterprise-уровня. В этом случае к стандартной поставке добавляется веб-интерфейс для администрирования, опциональные дашборды, дополнительная документация (hardening snippets) и развернутый план корректировки выявленных нарушений. И это еще не все, данное решение ко всему прочему можно получить в виде облачного сервиса (Software-as-a-Service).

Logo CISOfy

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

Поскольку Lynis весьма гибкий и многопрофильный инструмент, она используется для различных целей. К примеру, типовые варианты использования Lynis включают:

  • аудит безопасности (типовой сценарий, задаваемый пользователем);
  • тестирование на соответствие требованиям (например, PCI DSS, HIPAA, SOX404, OpenSCAP, NSA);
  • обнаружение уязвимостей (устаревшее ПО);
  • режим Penetration testing (попытка эскалации привилегий);
  • улучшение системы (незадействованные твики ядра, демонов и прочего).

Установить утилиту можно несколькими способами — как с помощью загрузки из хранилища GitHub:

git clone https://github.com/CISOfy/lynis
cd lynis
./lynis

так и установкой из репозитория Debian/Ubuntu:

sudo apt-get update
sudo apt-get install lynis

И для RPM-ориентированных дистрибутивов (предварительно добавив соответствующие репозитории):

yum install linus -y

Установка на macOS:

$ brew search lynis
$ brew install lynis

Чтобы запустить Lynis, достаточно указать хотя бы один ключ. К примеру, для запуска всех имеющихся тестов следует указать ключ -c (check all, проверить все):

# Типовой набор тестов
sudo lynis audit system
# Полный набор тестов
sudo lynis audit system -c
# Сканирование удаленного хоста
audit system remote <host>
Инициализация тестов
Результаты тестов из группы System Tool and Boot & Services
Результаты тестов из группы Kernel and Memory & Process auditing
Результаты тестов из группы User and Group & Authentication

Перед аудитом всегда полезно проверить, доступна ли новая версия Lynis:

lynis update info && lynis update check

У утилиты Lynis, помимо стандартного, существует еще один режим — непривилегированного запуска:

lynis audit --pentest

Если же ты хочешь поместить имя аудитора, запустившего тестирование, просто добавь параметр -auditor <name>:

sudo lynis audit system -c -auditor Daddy

На любом этапе аудита процесс проверки может быть продолжен (Enter) либо принудительно прекращен (Ctrl+C). Результаты выполненных тестов будут писаться в журнал Lynis в /var/log/lynis.log. Учти, что журнал будет перезаписываться при каждом следующем запуске утилиты.

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

#!/bin/sh
AUDITOR="automated"
DATE=$(date +%Y%m%d)
HOST=$(hostname)
LOG_DIR="/var/log/lynis"
REPORT="$LOG_DIR/report-${HOST}.${DATE}"
DATA="$LOG_DIR/report-data-${HOST}.${DATE}.txt"
cd /usr/local/lynis
./lynis -c –auditor "${AUDITOR}" –cronjob > ${REPORT}
mv /var/log/lynis-report.dat ${DATA}
# End

Сохрани этот скрипт в каталог /etc/cron.monthly/lynis. И не забудь добавить пути для сохранения логов (/usr/local/lynis и /var/log/lynis), иначе возможна некорректная работа.

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

lynis show commands
Вывод доступных команд

Особо любопытные могут глянуть настройки из конфига по умолчанию:

lynis show settings

Краткий инструктаж по работе с утилитой:

 man lynis

Варианты возможных статусов по результатам проверки ограничиваются следующим списком: NONE, WEAK, DONE, FOUND, NOT_FOUND, OK, WARNING.

Пример вывода статусов
Запуск отдельных тестов в Lynis

На практике бывает необходимо провести лишь некоторые тесты. К примеру, если твой сервак выполняет только функции Mail Server или Apache. Для этого мы можем использовать параметр -tests. Синтаксис команды выглядит следующим образом:

lynis -tests "Test-IDs"

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

./lynis -tests-category "firewalls kernel"
Пример запуска отдельных тестов

Список всех доступных тестов можно посмотреть в разделе Controls.

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

Предложения по исправлению (Suggestions)

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

Вывод рекомендаций, как устранять найденные проблемы
Профили

Профили, которые управляют аудитом, определяются в файлах с расширением .prf, расположенных в каталоге /etc/lynis. Профиль по умолчанию называется предсказуемо: default.prf. Разработчики не рекомендуют править его напрямую: любые изменения, которые ты хочешь внести в аудит, лучше добавлять в файл custom.prf, находящийся в том же каталоге.

Создаем и редактируем кастомный профиль:

touch /etc/lynis/custom.prf
sudo nano /etc/lynis/custom.prf

В этом файле можно определить список тестов, которые нужно исключить из аудита Lynis. Например:

  • FILE-6310: проверка разделов;
  • HTTP-6622: тест установки nginx;
  • HTTP-6702: тест установки Apache.

Чтобы исключить какой-то определенный тест, используй директиву skip-test и укажи ID теста. Например, так:

# Is nginx installed?
skip-test=HTTP-6622
# Is Apache installed?
skip-test=HTTP-6702
Оценка hardening state

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

Lynis security scan details:
Hardening index : 57 [############.........]
Tests performed : 216
Plugins enabled : 0
Итоговая оценка hardening state

Этот результат, выраженный числом, показывает количество пройденных тестов и индекс безопасности системы, то есть hardening index — итоговое число, с помощью которого Lynis оценивает общий уровень безопасности сервера. И очень важно не забывать, что индекс безопасности изменяется в зависимости от количества исправленных предупреждений и реализованных рекомендаций Lynis. Поэтому после фиксов повторный аудит может показать совсем другое число!

WARNING

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

2. Lunar — a UNIX security auditing tool based on several security frameworks

Lunar — это набор нативных скриптов, написанных на языке командной оболочки bash, которые тестируют целевую Linux-машину и генерируют по результатам проверки заключение аудита безопасности. Тулза основана на стандартах CIS и других мировых фреймворках по безопасности. Заявлена поддержка всех популярных систем: Linux — RHEL и CentOS с версии 5, SLES начиная с версии 10, Debian/Ubuntu, Amazon Linux, Solaris с версии 6, macOS (последние билды), FreeBSD (частично), AIX (частично) и даже ESXi.

Логотип Lunar

Кроме прочего, данная утилита поддерживает облачную платформу Amazon Web Services (AWS) и контейнеры Docker. Подробное описание всех фич, а также примеры запуска утилиты и инициации тестов приведены в документации Wiki на GitHub.

Просмотр всех параметров запуска Lunar

Запуск в режиме аудита, то есть без внесения изменений в систему:

 ./lunar.sh -a

Запуск в режиме аудита и предоставления большей информации:

./lunar.sh -a -v

Перечислить тесты:

./lunar.sh -S

Выполнять только тесты на основе оболочки:

./lunar.sh -s audit_shell_services

Запуск в режиме исправления, то есть с внесением изменений в систему:

 ./lunar.sh -l

Просмотр предлагаемых изменений (твиков) системы до их внесения в конфиги:

./lunar.sh -d
Пример запуска тестов для web-сервера Apache

3. Nix Auditor — a CIS Audit made easier

Nix Auditor — это еще один скрипт для проверки, соответствует ли безопасность Linux-систем требованиям бенчмарка CIS. Ориентирован на RHEL, CentOS и прочие RPM-дистрибутивы.

Разработчики заявляют о таких преимуществах Nix Auditor:

  • скорость сканирования — провести базовую проверку ОС можно менее чем за 120 секунд и тут же получить отчет;
  • точность проверки — работа утилиты проверена на разных версиях дистрибутивов CentOS и Red Hat;
  • настраиваемость — исходники с документацией к программе лежат на GitHub, поэтому код легко настраивается в соответствии с типом ОС и набором элементов системы, которые необходимо проверить;
  • простота использования — достаточно сделать стартовый скрипт исполняемым, и тот готов к проверке.

Пример выполнения команд для загрузки утилиты с GitHub-хранилища и последующего запуска скрипта:

git clone https://github.com/XalfiE/Nix-Auditor.git
cd Nix-Auditor
chmod +x nixauditor
./nixauditor
Пример вывода информации после запуска Nix Auditor

4. Loki — Simple IOC and Incident Response Scanner

Утилита Loki — не совсем классический инструмент для проведения аудита ИБ, однако отлично подходит для поиска следов взлома, что отчасти можно отнести и к практике аудита.

Логотип Loki Scanner

По заверениям разработчиков, вот такие возможности дает нам их тулза:

I. Четыре способа выявления взлома:

  • имена файлов (соответствие регулярному выражению полного пути файла);
  • проверка в соответствии с правилами Yara (поиск на соответствие сигнатурам Yara по содержимому файлов и памяти процессов);
  • проверка хешей (сравнение просканированных файлов с хешами (MD5, SHA-1, SHA-256) известных вредоносных файлов);
  • проверка обратной связи C2 (сравнивает конечные точки технологического соединения с C2 IOC).

II. Дополнительные проверки:

  • проверка файловой системы Regin (через --reginfs);
  • проверка аномалий системных и пользовательских процессов;
  • сканирование распакованных SWF;
  • проверка дампа SAM;
  • проверка DoublePulsar — попытка выявить бэкдор DoublePulsar, слушающий порты 445/tcp и 3389/tcp.

Чуть-чуть коснемся того, как Loki определяет факт компрометации. Типовыми признаками (Indicators of Compromise), свидетельствующими, что компьютер был скомпрометирован (то есть взломан), могут быть:

  • появление на компьютере malware (вирусов, бэкдоров, троянов, кейлоггеров, крипторов, майнеров и так далее), а также хакерских утилит (например, для исследования сети, эксплуатации уязвимостей, сбора учетных данных);
  • появление неизвестных новых исполняемых и других файлов, даже если они не детектируются антивирусным движком как malware-код;
  • аномальная сетевая активность (подключение к удаленным хостам, открытие для прослушивания портов неизвестными программами и прочее);
  • аномальная активность на дисковых устройствах (I/O) и повышенное потребление ресурсов системы (CPU, RAM, Swap).

Перед началом инсталляции нужно доустановить несколько зависимых пакетов. Это colorama (дает расцветку строк в консоли), psutil (утилита проверки процессов) и, если еще не установлен, пакет Yara.

Итак, приступаем. Установка в Kali Linux (предварительно должен быть установлен пакет Yara, который по умолчанию уже инсталлирован в Kali Linux):

sudo pip2 install psutil netaddr pylzma colorama
git clone https://github.com/Neo23x0/Loki
cd Loki/
python2 loki-upgrader.py
python2 loki.py -h

Установка в Ubuntu/Debian:

sudo apt-get install yara python-yara python-pip python-setuptools python-dev git
sudo pip2 install --upgrade pip
sudo pip2 install -U setuptools
sudo pip2 install psutil netaddr pylzma colorama
git clone https://github.com/Neo23x0/Loki
cd /home/download/Loki
python2 loki-upgrader.py
python2 loki.py -h

Установка в BlackArch:

sudo pacman -S yara python2-pip python2-yara
sudo pip2 install psutil netaddr pylzma colorama
git clone https://github.com/Neo23x0/Loki
cd /home/download/Loki
python2 loki-upgrader.py
python2 loki.py -h

Пример использования

Некоторые опции запуска:

optional arguments:
  -h, --help      show this help message and exit
  -p path         Path to scan
  -l log-file     Log file
  --printAll      Print all files that are scanned
  --noprocscan    Skip the process scan
  --nofilescan    Skip the file scan
  --noindicator   Do not show a progress indicator
  --reginfs       Do check for Regin virtual file system
  --onlyrelevant  Only print warnings or alerts
  --nolog         Don't write a local log file
Loki Scanner после первого запуска

Кстати, после установки утилиты неплохо бы проверить локальную базу IoC на обновления, сделать это можно с помощью команды Upgrader:

Loki - Upgrader

optional arguments:
  -h, --help   show this help message and exit
  --sigsonly   Update the signatures only
  --progonly   Update the program files only
  --nolog      Don’t write a local log file
  --debug      Debug output
Пример ведения лога при сканировании

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

Информация об обнаруженных вредоносных файлах

5. Linux Security Auditing Tool (LSAT)

LSAT — заключительный в нашей подборке инструмент аудита безопасности Linux. Особенность данной тулзы в ее модульном дизайне, который, по заверениям разработчика, позволяет добавлять новые функции проверки очень оперативно. На сегодняшний момент в утилите заявлена поддержка всех самых распространенных ОС: Linux — Gentoo, Red Hat, Debian, Mandrake на архитектуре x86; SunOS (2.x), Red Hat, Mandrake на архитектуре Sparc; а также Apple macOS.

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

./configure
make
# Также можно установить LSAT в систему, путь расположения /usr/local/bin
make install
# и очистить постинсталляционные файлы
make clean

Либо для Debian/Ubuntu-дистрибутивов установить пакет можно прямо из репозитория:

sudo apt-get install lsat

Запускается утилита с помощью команды /lsat и добавленными опциями:

/lsat [OPTIONS]

Options:
    -d        diff current and old md5, output in lsatmd5.diff
    -f        Force a specific distribution test. Distro names are:
                  redhat
                  debian
                  mandrake
                  solaris
                  gentoo
                  macosx
                  If no -f option, lsat will guess. If lsat can
                  not guess the distribution, default is redhat.
    -a        Show this (advanced) help page
    -o        Output file name -- default is lsat.out
    -r        Check rpm integrity -- redhat or mandrake only
    -s        Silent mode
    -v        Verbose output
    -w        Output file in html format
    -x        eXclude module(s) in filelist from checks..

Заключение

Мы рассмотрели с тобой самые ходовые и в то же время очень крутые и функциональные тулзы для аудита безопасности Linux-серверов. Теперь ты сможешь хорошо подготовиться к сертификационному или какому-либо другому compliance-аудиту. Это также позволит тебе объективно оценить текущий уровень защищенности и в автоматическом или полуавтоматическом режиме оттюнинговать свою ферму Linux-машин на максимальный показатель hardening index!

Иван Пискунов: Технический эксперт, ресерчер, участник CTF-команды CraZY Geek$, 10 лет в индустрии ИБ. Автор блога ipiskunov.blogspot.com. Канал в telegram @w2hack или t.me/w2hack. Увлекается миром Unix, malware analysis, reverse engineering и тестированием сетей на проникновение

Комментарии (3)

  • Ценю статейный труд, отнимает много времени, но статья утарела и и поданная информация находится в общем доступе. Статья не актулизирована и сделана чтобы набить побольше знаков:
    1. Опции "-с" нет уже давно.
    2. Команда sudo lynis audit system -c -auditor Daddy тоже не работает. В текущей справке нет команды "-auditor"

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

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

Похожие материалы