os hardening что это
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», Приглашаем всех желающих на бесплатный вебинар, в рамках которого наши эксперты подробно расскажут о курсе, процессе обучения, а также карьерных перспективах в данной сфере.
Linux. Как работает hardening
Статья расскажет о том, как с помощью kconfig hardened check можно проверить настройку механизмов защиты ядра ОС Linux, которые используются для противодействия эксплойтам. На сегодняшний день данный инструмент, пожалуй, является одним из самых опасных инструментов нарушения разграничения доступа и функционирования ОС. Рассмотрим, какие основные параметры компиляции ядра и модули безопасности есть в официальном репозитории, а также попробуем выяснить, какие наборы механизмов применяются в различных дистрибутивах.
Инструменты и источники для проведения исследования
Исследование ОС Linux будем традиционно проводить на базе исходного кода, который доступен в официальном репозитории. В качестве инструментов исследования будем использовать:
Visual Studio Code;
Python в этом случае необходим для построение иерархии директорий, которые содержат исходный код. Именно этот метод верхнеуровневого представления будет использован как основной для исследования.
Подсистемы защиты
Головная боль любой ОС — разграничение доступа и уязвимости, которые приводят к повреждению памяти. Исторически сложилось так, что для создания ОС используются языки программирования, которые имеют определенные проблемы при неверной обработке памяти.
В ОС Linux с точки зрения защиты от различных атак на разграничение доступа и эксплуатацию уязвимостей используют следующие механизмы:
LSM фреймворк — механизм перехвата системных функций для обработки расширениями ядра Linux;
KASLR — рандомизация адресного пространства ядра;
HW-Vuln — митигации и патчи, которые используются против Hardware уязвимостей (Meltdown, Spectre, и т.д.);
Параметризация сборки и запуска ядра. Большое количество работающих алгоритмов в ядре — это потенциальный вектор для атаки, поэтому здесь исходят из минимально необходимого функционала, который можно оставить и при этом максимально уменьшить возможности проведения атак.
Большая часть механизмов противодействия атакам на разграничение доступа и эксплуатации уязвимостей находится в разделе linux/security :
Здесь в явном виде представлены модули ядра, которые можно использовать для улучшения механизмов защиты. Есть только маленькая неприятность — некоторые модули из этой директории не могут быть совместимы. На сегодняшний день, к сожалению, нет метода использования сразу несколько модулей LSM. Поэтому предполагается, что тот, кто хочет собрать себе ядро для своей ОС, должен самостоятельно решить, что за модуль ему подойдет больше. Всего их 11 штук:
Например, модуль toyomo нельзя использовать с другими модулями.
Выходит, что механизмы есть, но на выбор нужно собирать себе обойму самостоятельно. Это не удивительно, так как ядро Linux предоставляется для большого количества дистрибутивов, и поэтому разработчики отдельных дистрибутивов должны заниматься более тонкой настройкой. Давайте попытаемся выяснить, а что работает в конкретных дистрибутивах.
Ubuntu и его механизмы защиты
Вообще в репозитории есть 2 вида конфигов — обычный, который создан для конкретного дистрибутива, и рекомендуемый с точки зрения наибольшего количества безопасных опций. Ресурс kernsec характеризует KSSP конфиг как наиболее параноидальный с точки зрения колиества применяемых параметоров. Результат для Ubuntu Server 20.04:
29 опций, которые не используются или не найдены из 111. Не такой уж плохой результат. Особенно если учесть, что конфиг эталона — параноидальный.
Debian и его механизмы защиты
Для исследования Debian был выбран неофициальный дистрибутив Debian, а его модифкация — Kali Linux. Этот дистрибутив, который используют для тестирования на проникновение, посмотрим что у него у самого с параметрами безопасности:
Дистрибутив несмотря на то, что используется для узкого спектра задач все же содержит в себе достаточное количество опций и параметров ядра для противодействия атакам.
Таким образом можно выяснять, как настроен тот дистрибутив, которым вы пользуетесь на базе ядра ОС Linux.
Прямо сейчас в OTUS открыт набор на новый поток курса «Administrator Linux. Basic», Приглашаем всех желающих на бесплатный вебинар, в рамках которого наши эксперты подробно расскажут о курсе, процессе обучения, а также карьерных перспективах в данной сфере.
Записаться на вебинар.
Ядерная защита в 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 будет отсутствовать.
Hardening на практике
В преддверии старта курса «Administrator Linux. Professional» подготовили статью, автором которой является Александр Колесников. Если вам интересно узнать подробнее об обучении на курсе, приходите на демо-день курса.
В предыдущей статье рассматривался пример уязвимых машин, которые создавались для того чтобы их использовать в практике тестирования систем на наличие уязвимостей. Эта статья расскажет как нестандартно можно обнаружить уязвимости в системах, если мы, к примеру, получили их уже в работоспособном состоянии и их ни в коем случае нельзя выводить из строя, а продолжать поддерживать.
Hardening
Процесс закрытия возможных уязвимостей на совершенно неизвестной машине это достаточно серьезный вызов. Во-первых, никогда не знаешь какой сервис перестанет работать если изменить отдельную настройку файрволла или всей операционной системы.
Проблема достаточно не нова, и естественно есть руководства на 100500 страниц, которые, если правильно им следовать должны спасти от неминуемых проблем. Примеры таких руководств можно найти тут, тут и тут. Список далеко не полный, представлены лишь самые интересные с точки зрения автора.
Но это статья не о том как пройтись по списку формально описанных действий и придумать как их реализовать. Давайте попробуем сделать немного иначе. Что если прибегнуть к помощи не администраторских инструментов, а пентестерских?
В наборе любого энтузиаста или профессионального пентестера есть проект или скрипт, который должен проверять стандартные отклонения от безопасной конфигурации для различных систем. Обычно концентрируются на самых популярных: Windows, Linux, macOS. И именно в этой последовательности, потому что они настолько популярны в энтерпрайз среде.
Для закрытия всех векторов атак разобьем их группы:
Атаки, которые работают в приложениях доступных во внешний мир
Атаки, которые работают внутри ОС и их цель повышение привилегий
Для первого вида атак можно использовать сканеры безопасности. Мы будем использовать набор инструментов машины Kali Linux. Это nmap, Burp Suite и т.д.
Для второго типа атак предлагаем ознакомиться с вот этим проектом. Так как процедура поиска неверных конфигураций в большинстве случаев детерминирована, то это просто автоматизировать. Запускаем команду для получения данных конфигурации и парсим результат — готово. Использовать скрипы достаточно просто, необходимо выбрать нужный для платформы и скопировать его в рабочую директорию уязвимой машины. Скрипты не запускают никаких атак, единственная их задача это показать, что уязвимость может присутствовать в системе и предложить ссылку на статью с атакой. Скрипт это автоматизация и поэтому следует ожидать, что он может давать ложные срабатывания на вероятные уязвимости. Каждый отдельный случай придётся рассматривать отдельно.
Уязвимые стенды
Чтобы сделать процесс еще более непредсказуемее. Пронумеруем создаваемые машины и будем генерировать номер машины по следующей команде:
Скрипт подразумевает, что на каждый его запуск будет создана рандомная уязвимая машина, которую и нужно поправить, чтобы нельзя было её взломать тем способом, который был заложен в нее при сборке. Дополнительное условие на вмешательство — каким бы простым и бесполезным не выглядел сервис внутри этой машины, он должен продолжить функционировать после внесения изменений.
В сравнении с прошлым нашим экспериментом, теперь все машины будут иметь разные классы уязвимостей. С помощью них можно будет не только повысить привилегии, но и просто выполнить команды от имени пользователя.
Эксперимент
Для первого эксперимента будем использовать вот этот box. Проведем эксперимент в 2 этапа.
Этап 1 — поиск уязвимых конфигураций и сервисов работающих снаружи сервера. Первые команды для запуска:
В результате вот такой список сервисов, которые видны извне сервера:
У нас есть доступ к пользователю внутри машины, поэтому еще попробуем узнать какие порты открыты:
Получается, что единственный сервис на 80м порту. Проведем сбор данных о структуре веб-приложений, которые могут там работать:
Итог работы инструмента:
Похоже, что это wordpress. в директориях сервера лежит версия WordPress 5.6 и плагин «contact-form». Для этого набора данных очень хорошо подходит CVE-2020-35489. Тестовый скрипт можно найти тут. Попробуем протестировать сервис. Скрипт так и не захотел работать, но по сути их него функциональна только одна строка, которая отправляет запрос на адрес «/wp-content/plugins/contact-form-7/readme.txt». Если его выполнить, то можно увидеть, что используемый плагин может быть уязвим для атаки.
Второй этап тестирования. Запускаем скрипт, который описывали выше и ждем результата. Ниже приведем выводы скрипта:
Первая конфигурационная уязвимость. Как видно из снимка, нас интересуют те записи, которые выделены красным цветом. На самом деле это единственная уязвимость, не считая наличие пользователя vagrant в системе.
Таким образом можно получить информацию о уязвимостях на незнакомом сервере. Дальнейшие исправления зависят от функциональности сервера. Читателю предлагается так же пройти эксперимент самостоятельно, но использовать вот этот box.
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