Linux hardening что это
Ядерная защита в Astra Linux SE 1.6 и как ее включить. Ядро Hardened
Как защититься от ядерных эксплоитов эксплуатирующих уязвимости ядра Linux? Рассмотрим как это реализовано в отечественной ОС Astra Linux SE 1.6.
Ядро hardened в Astra Linux SE 1.6
Ядро hardened — это несколько изменений в компиляторе и ядре, которые увеличивают общую защищенность системы от взлома. Ядро hardened умеет блокировать массу потенциально опасных операций. В ОС Astra Linux SE 1.6 поставляется две версии ядра — это hardened и generic. Ядро hardened более компактное по размеру. Из него убраны многие компоненты, которые не используются для обычной работы, но могут использоваться для отладки. Так же в этом ядре присутствуют технологии, которые обеспечивают очистку информации стека ядра после системных вызовов. Это позволяет защититься от некоторых эксплоитов, которые нацелены на считывание неочищенной информации после системных вызовов.
На практике hardened ядро на несколько (2-3%) медленнее, чем ядро generic, но оно обеспечивает эффективную защиту от эксплоитов, которые нацелены на эксплуатацию уязвимостей ядра (ядерных эксплоитов).
Ограничения по работе с памятью в ядре hardened:
Включаем использование ядра hardened в Astra Linux SE 1.6
Включить использование ядра hardened можно во время установки Astra Linux SE 1.6 и позже, уже непосредственно в установленной ОС.
Во время установки Astra Linux SE 1.6 эта настройка делается в разделе «Дополнительные настройки ОС».
Для того, чтобы ОС по умолчанию загружала ядро hardened необходимо отметить параметр «Использовать по умолчанию ядро Hardened».
Так же, чтобы исключить возможность выбора пользователем варианта загрузки незащищенного ядра generic, необходимо в этом же разделе установить параметр «Запретить вывод меню загрузчика».
Если Вы не установите параметры описанные выше, и продолжите установку Astra Linux SE 1.6, то после установки ОС, во время загрузки, по умолчанию будет загружаться незащищенное ядро generic, а не hardened. Так же, с такими настройками, у пользователя будет возможность выбора ядра generic для загрузки.
Скорее всего, такая ситуация с загрузкой по умолчанию незащищенного ядра generic встретится у многих администраторов. Для того, чтобы настроить загрузку защищенного ядра hardened в уже установленной ОС, необходимо администратором (высокоцелостным root) в графическом интерфейсе открыть — «Панель управления — Система — Загрузчик GRUB2» и сделать следующие настройки:
После этих настроек, ОС будет сразу загружаться с защищенным ядром hardened, а возможность у пользователя выбрать для загрузки незащищенное ядро generic будет отсутствовать.
Ядерная защита в Astra Linux SE 1.6 и как ее включить. Ядро Hardened
Как защититься от ядерных эксплоитов эксплуатирующих уязвимости ядра Linux? Рассмотрим как это реализовано в отечественной ОС Astra Linux SE 1.6.
Ядро hardened в Astra Linux SE 1.6
Ядро hardened — это несколько изменений в компиляторе и ядре, которые увеличивают общую защищенность системы от взлома. Ядро hardened умеет блокировать массу потенциально опасных операций. В ОС Astra Linux SE 1.6 поставляется две версии ядра — это hardened и generic. Ядро hardened более компактное по размеру. Из него убраны многие компоненты, которые не используются для обычной работы, но могут использоваться для отладки. Так же в этом ядре присутствуют технологии, которые обеспечивают очистку информации стека ядра после системных вызовов. Это позволяет защититься от некоторых эксплоитов, которые нацелены на считывание неочищенной информации после системных вызовов.
На практике hardened ядро на несколько (2-3%) медленнее, чем ядро generic, но оно обеспечивает эффективную защиту от эксплоитов, которые нацелены на эксплуатацию уязвимостей ядра (ядерных эксплоитов).
Ограничения по работе с памятью в ядре hardened:
Включаем использование ядра hardened в Astra Linux SE 1.6
Включить использование ядра hardened можно во время установки Astra Linux SE 1.6 и позже, уже непосредственно в установленной ОС.
Во время установки Astra Linux SE 1.6 эта настройка делается в разделе «Дополнительные настройки ОС».
Для того, чтобы ОС по умолчанию загружала ядро hardened необходимо отметить параметр «Использовать по умолчанию ядро Hardened».
Так же, чтобы исключить возможность выбора пользователем варианта загрузки незащищенного ядра generic, необходимо в этом же разделе установить параметр «Запретить вывод меню загрузчика».
Если Вы не установите параметры описанные выше, и продолжите установку Astra Linux SE 1.6, то после установки ОС, во время загрузки, по умолчанию будет загружаться незащищенное ядро generic, а не hardened. Так же, с такими настройками, у пользователя будет возможность выбора ядра generic для загрузки.
Скорее всего, такая ситуация с загрузкой по умолчанию незащищенного ядра generic встретится у многих администраторов. Для того, чтобы настроить загрузку защищенного ядра hardened в уже установленной ОС, необходимо администратором (высокоцелостным root) в графическом интерфейсе открыть — «Панель управления — Система — Загрузчик GRUB2» и сделать следующие настройки:
После этих настроек, ОС будет сразу загружаться с защищенным ядром hardened, а возможность у пользователя выбрать для загрузки незащищенное ядро generic будет отсутствовать.
Linux. Как работает hardening
Статья расскажет о том, как с помощью kconfig hardened check можно проверить настройку механизмов защиты ядра ОС Linux, которые используются для противодействия эксплойтам. На сегодняшний день данный инструмент, пожалуй, является одним из самых опасных инструментов нарушения разграничения доступа и функционирования ОС. Рассмотрим, какие основные параметры компиляции ядра и модули безопасности есть в официальном репозитории, а также попробуем выяснить, какие наборы механизмов применяются в различных дистрибутивах.
Инструменты и источники для проведения исследования
Исследование ОС Linux будем традиционно проводить на базе исходного кода, который доступен в официальном репозитории. В качестве инструментов исследования будем использовать:
Visual Studio Code;
Python в этом случае необходим для построение иерархии директорий, которые содержат исходный код. Именно этот метод верхнеуровневого представления будет использован как основной для исследования.
Подсистемы защиты
Головная боль любой ОС — разграничение доступа и уязвимости, которые приводят к повреждению памяти. Исторически сложилось так, что для создания ОС используются языки программирования, которые имеют определенные проблемы при неверной обработке памяти.
В ОС Linux с точки зрения защиты от различных атак на разграничение доступа и эксплуатацию уязвимостей используют следующие механизмы:
LSM фреймворк — механизм перехвата системных функций для обработки расширениями ядра Linux;
KASLR — рандомизация адресного пространства ядра;
HW-Vuln — митигации и патчи, которые используются против Hardware уязвимостей (Meltdown, Spectre, и т.д.);
Параметризация сборки и запуска ядра. Большое количество работающих алгоритмов в ядре — это потенциальный вектор для атаки, поэтому здесь исходят из минимально необходимого функционала, который можно оставить и при этом максимально уменьшить возможности проведения атак.
Большая часть механизмов противодействия атакам на разграничение доступа и эксплуатации уязвимостей находится в разделе linux/security :
Здесь в явном виде представлены модули ядра, которые можно использовать для улучшения механизмов защиты. Есть только маленькая неприятность — некоторые модули из этой директории не могут быть совместимы. На сегодняшний день, к сожалению, нет метода использования сразу несколько модулей LSM. Поэтому предполагается, что тот, кто хочет собрать себе ядро для своей ОС, должен самостоятельно решить, что за модуль ему подойдет больше. Всего их 11 штук:
Например, модуль tomoyo нельзя использовать с другими модулями.
Выходит, что механизмы есть, но на выбор нужно собирать себе обойму самостоятельно. Это не удивительно, так как ядро Linux предоставляется для большого количества дистрибутивов, и поэтому разработчики отдельных дистрибутивов должны заниматься более тонкой настройкой. Давайте попытаемся выяснить, а что работает в конкретных дистрибутивах.
Ubuntu и его механизмы защиты
Вообще в репозитории есть 2 вида конфигов — обычный, который создан для конкретного дистрибутива, и рекомендуемый с точки зрения наибольшего количества безопасных опций. Ресурс kernsec характеризует KSSP конфиг как наиболее параноидальный с точки зрения количества применяемых параметоров. Результат для Ubuntu Server 20.04:
29 опций, которые не используются или не найдены из 111. Не такой уж плохой результат. Особенно если учесть, что конфиг эталона — параноидальный.
Debian и его механизмы защиты
Для исследования Debian был выбран неофициальный дистрибутив Debian, а его модификация — Kali Linux. Этот дистрибутив, который используют для тестирования на проникновение, посмотрим что у него у самого с параметрами безопасности:
Дистрибутив несмотря на то, что используется для узкого спектра задач все же содержит в себе достаточное количество опций и параметров ядра для противодействия атакам.
Таким образом можно выяснять, как настроен тот дистрибутив, которым вы пользуетесь на базе ядра ОС Linux.
Прямо сейчас в OTUS открыт набор на новый поток курса «Administrator Linux. Basic», Приглашаем всех желающих на бесплатный вебинар, в рамках которого наши эксперты подробно расскажут о курсе, процессе обучения, а также карьерных перспективах в данной сфере.
Hardening — путь самурая
Содержание статьи
Сегодня мы поговорим о такой важной составляющей ИБ, как укрепление сервера (hardening). Мы рассмотрим базовый подход к укреплению классического Linux сервера и разберем, насколько данный процесс важен и полезен.
Введение
Результат работы утилиты PHP Auditor
Хакер #171. 3D-принтеры
Допустим у нас есть система, построенная на Linux/Apache/MySQL/PHP. Мейнстрим, но мы потерпим. Давай предположим, что у нас есть фронт-енд, торчащий в интернет (Linux/Apache/PHP) и бэк-енд (Linux/MySQL). Мы опустим бэкапы, балансировку и защиту от DDoS на уровне архитектурных решений, ну и о MySQL, PHP и Apache мы поговорим, может быть, потом. Сегодня только ОС.
Linux Hardening
«Сеть — это Компьютер» (с), так что начнем наш процесс с настроек TCP/IP. В целом, еще нет глобальной поддержки ipv6, поэтому можно смело отключать поддержку этого протокола на сетевых интерфейсах. IPv6 довольно молодой и дырявый протокол, лишних проблем с его настройками нам не надо, как и лишних угроз.
Таким же образом проверяем остальные сетевые настройки:
Есть и другие фичи для параноиков, но это базовые. Кто-то не любит пинги вообще, а у некоторых так health_check делается, поэтому здесь советовать сложно. Все проверки легко автоматизируются, что полезно, если ты производишь авто-деплоймент.
Кое-что про фаервол. Это вопрос архитектуры системы, то есть, например, если наша машинка работает в Амазоне или же вся сетка режется каким-то красивым роутером/межсетевым экраном или хитрыми VLAN’ами, то ясно, что вся фильтрация и логика доступа будет там, но если мы закидываем сервак в непонятный дата-центр, где у нас куча других проектов, то возникает угроза горизонтальных атак в пределах дата-центра. То есть наш MySQL сервер не видит инета, и его не видно из инета, но другие хосты дата-центра его видят. В таком варианте локальные правила фильтрации будут нелишними. Проверить это автоматом сложно, так как по умолчанию, особенно если проектов много, ты не знаешь, кому какие правила доступа требуются, и нужно все внимательно изучать и допиливать. Но вот быстрый чек замутить можно:
Аккаунты
Кроме сети, у нас еще есть стандартные сервисы, типа SSH. Требования здесь достаточно просты:
Большая часть чеков так же легко автоматизируется, не буду тут это расписывать.
Tiger security scripts в действии
Файловая система
Это самая важная часть. Например, классикой жанра является уязвимость LFI, и раньше было модно инъектить в логи апача PHP код для дальнейшего RCE. Это, конечно, старый и унылый пример, но это показывает силу хардининга. Дело в том, что Апач у нас пишет логи от рута, а вот дочерние процессы (форки) запущены с правами непривилегированного пользователя, например apache. Так вот, в идеальном мире этот юзер не должен иметь прав на чтение в директории /var/log/httpd/, что сведет к неудаче попытку чтения через LFI (но мы-то, конечно, знаем про phpinfo и upload директорию…) И это минимальный пример. В других примерах есть куча директорий и файлов, которые не желательны для доступа другим юзерам, типа apache. Это различные конфиги, логи и бэкапы, в которых может быть чувствительная информация и, о нет, персональные данные. Для автоматизации этого чека можно запилить скрипт, который проверяет права чтения и записи «для всех». Может оказаться полезным.
Кроме того, имеет смысл сварганить скрипт, который ищет чувствительные данные по ФС. Зачем это нужно? Очень просто, запускаем этот скрипт от юзера апач или даже рута, он мучается несколько минут, а затем должен показать, что он ничего не нашел в открытом и доступном виде. Этот трик применяется всеми вменяемыми PCI DSS аудиторами, которые по регекспам ищут следы номеров кредитных карт, и если такой скрипт находит их, то аудитор справедливо выписывает пачку люлей 8). Соответственно, мы определяем, какие данные для нас важны, и какие данные мы защищаем, затем пишем их фингерпринт и чекаем автоматом, что фактически означает быструю проверку на тему «не может ли хакИр, в случае RCE, LFI или Traversal, найти что-то ценное». Примеры таких данных:
SeLinux/AppArmor
Отдельно хочется сказать про этот слой защиты. На самом деле, данные системы контроля доступа на уровне ядра являются очень эффективными инструментами. Но вот их настройка дело сложное, и не всегда тривиальное. Крайне рекомендую озаботиться, но стоит помнить, что любые изменения в логике работы системы могут быть заблокированы SeLinux/AppArmor, что приводит к дополнительным проблемам с поддержкой системы.
Итд Итп
Алексей Синцов
Известный white hat, докладчик на security-конференциях, соорганизатор ZeroNights и просто отличный парень. В данный момент занимает должность Principal Security Engineer в компании Nokia, где отвечает за безопасность сервисов платформы HERE
Жесткая закалка 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.
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).
Xakep #235. Возрождение эксплоит-китов
Lynis выполняет сотни отдельных тестов, чтобы определить состояние защищенности системы. Сама проверка защищенности заключается в выполнении набора шагов от инициализации программы до генерации отчета.
Поскольку Lynis весьма гибкий и многопрофильный инструмент, она используется для различных целей. К примеру, типовые варианты использования Lynis включают:
Установить утилиту можно несколькими способами — как с помощью загрузки из хранилища GitHub:
так и установкой из репозитория Debian/Ubuntu:
И для RPM-ориентированных дистрибутивов (предварительно добавив соответствующие репозитории):
Установка на macOS:
Инициализация тестов 
Результаты тестов из группы System Tool and Boot & Services 
Результаты тестов из группы Kernel and Memory & Process auditing 
Результаты тестов из группы User and Group & Authentication
Перед аудитом всегда полезно проверить, доступна ли новая версия Lynis:
У утилиты Lynis, помимо стандартного, существует еще один режим — непривилегированного запуска:
Можно посмотреть список всех доступных для вызова команд:
Вывод доступных команд
Особо любопытные могут глянуть настройки из конфига по умолчанию:
Краткий инструктаж по работе с утилитой:
Варианты возможных статусов по результатам проверки ограничиваются следующим списком: NONE, WEAK, DONE, FOUND, NOT_FOUND, OK, WARNING.
Пример вывода статусов
Запуск отдельных тестов в Lynis
Пример запуска отдельных тестов
Список всех доступных тестов можно посмотреть в разделе Controls.
Помимо этого, функциональность Lynis расширяют различные плагины, которые можно дописывать самостоятельно, а можно подкладывать новые в существующую директорию.
Предложения по исправлению (Suggestions)
Все предупреждения (Warnings) будут перечислены после результатов. Каждое начинается с текста предупреждения, потом рядом в скобках указывается тест, который его сгенерировал. В следующей строке предлагается решение проблемы, если оно существует. По факту последняя строка — это URL-адрес, по которому ты сможешь посмотреть подробности и найти дополнительные рекомендации, как устранить возникшую проблему.
Вывод рекомендаций, как устранять найденные проблемы
Профили
Создаем и редактируем кастомный профиль:
В этом файле можно определить список тестов, которые нужно исключить из аудита Lynis. Например:
Чтобы исключить какой-то определенный тест, используй директиву skip-test и укажи ID теста. Например, так:
Оценка hardening state
По результатам выполнения всех тестов в конце каждого вывода аудита утилиты (чуть ниже раздела предложений) ты найдешь раздел, который будет выглядеть приблизительно следующим образом:
Итоговая оценка 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.
Кроме прочего, данная утилита поддерживает облачную платформу Amazon Web Services (AWS) и контейнеры Docker. Подробное описание всех фич, а также примеры запуска утилиты и инициации тестов приведены в документации Wiki на GitHub.
Просмотр всех параметров запуска Lunar
Запуск в режиме аудита, то есть без внесения изменений в систему:
Запуск в режиме аудита и предоставления большей информации:
Выполнять только тесты на основе оболочки:
Запуск в режиме исправления, то есть с внесением изменений в систему:
Просмотр предлагаемых изменений (твиков) системы до их внесения в конфиги:
Пример запуска тестов для web-сервера Apache
3. Nix Auditor — a CIS Audit made easier
Nix Auditor — это еще один скрипт для проверки, соответствует ли безопасность Linux-систем требованиям бенчмарка CIS. Ориентирован на RHEL, CentOS и прочие RPM-дистрибутивы.
Разработчики заявляют о таких преимуществах Nix Auditor:
Пример выполнения команд для загрузки утилиты с GitHub-хранилища и последующего запуска скрипта:
Пример вывода информации после запуска Nix Auditor
4. Loki — Simple IOC and Incident Response Scanner
Утилита Loki — не совсем классический инструмент для проведения аудита ИБ, однако отлично подходит для поиска следов взлома, что отчасти можно отнести и к практике аудита.
Логотип Loki Scanner
По заверениям разработчиков, вот такие возможности дает нам их тулза:
I. Четыре способа выявления взлома:
II. Дополнительные проверки:
Чуть-чуть коснемся того, как Loki определяет факт компрометации. Типовыми признаками (Indicators of Compromise), свидетельствующими, что компьютер был скомпрометирован (то есть взломан), могут быть:
Перед началом инсталляции нужно доустановить несколько зависимых пакетов. Это colorama (дает расцветку строк в консоли), psutil (утилита проверки процессов) и, если еще не установлен, пакет Yara.
Итак, приступаем. Установка в Kali Linux (предварительно должен быть установлен пакет Yara, который по умолчанию уже инсталлирован в Kali Linux):
Установка в Ubuntu/Debian:
Установка в BlackArch:
Пример использования
Некоторые опции запуска:
Loki Scanner после первого запуска
Кстати, после установки утилиты неплохо бы проверить локальную базу IoC на обновления, сделать это можно с помощью команды Upgrader:
Пример ведения лога при сканировании
В первую очередь пристальное внимание обращаем на сообщения, выделенные красным. В поле 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.
Либо для Debian/Ubuntu-дистрибутивов установить пакет можно прямо из репозитория:
Запускается утилита с помощью команды /lsat и добавленными опциями:
Заключение
Мы рассмотрели с тобой самые ходовые и в то же время очень крутые и функциональные тулзы для аудита безопасности Linux-серверов. Теперь ты сможешь хорошо подготовиться к сертификационному или какому-либо другому compliance-аудиту. Это также позволит тебе объективно оценить текущий уровень защищенности и в автоматическом или полуавтоматическом режиме оттюнинговать свою ферму Linux-машин на максимальный показатель hardening index!