Безопасность ос семейства linux

Системы защиты Linux

Одна из причин грандиозного успеха Linux ОС на встроенных, мобильных устройствах и серверах состоит в достаточно высокой степени безопасности ядра, сопутствующих служб и приложений. Но если присмотреться внимательно к архитектуре ядра Linux, то нельзя в нем найти квадратик отвечающий за безопасность, как таковую. Где же прячется подсистема безопасности Linux и из чего она состоит?

Предыстория Linux Security Modules и SELinux

Security Enhanced Linux представляет собой набор правил и механизмов доступа, основанный на моделях мандатного и ролевого доступа, для защиты систем Linux от потенциальных угроз и исправления недостатков Discretionary Access Control (DAC) — традиционной системы безопасности Unix. Проект зародился в недрах Агентства Национальной Безопасности США, непосредственно разработкой занимались, в основном, подрядчики Secure Computing Corporation и MITRE, а также ряд исследовательских лабораторий.

Linux Security Modules

Линус Торвальдс внес ряд замечаний о новых разработках АНБ, с тем, чтобы их можно было включить в основную ветку ядра Linux. Он описал общую среду, с набором перехватчиков для управления операциями с объектами и набором неких защитных полей в структурах данных ядра для хранения соответствующих атрибутов. Затем эта среда может использоваться загружаемыми модулями ядра для реализации любой желаемой модели безопасности. LSM полноценно вошел в ядро Linux v2.6 в 2003 году.

Фреймворк LSM включает защитные поля в структурах данных и вызовы функций перехвата в критических точках кода ядра для управления ими и выполнения контроля доступа. Он также добавляет функции для регистрации модулей безопасности. Интерфейс /sys/kernel/security/lsm содержит список активных модулей в системе. Хуки LSM хранятся в списках, которые вызываются в порядке, указанном в CONFIG_LSM. Подробная документация по хукам включена в заголовочный файл include/linux/lsm_hooks.h.

Подсистема LSM позволила завершить полноценную интеграцию SELinux той же версии стабильного ядра Linux v2.6. Буквально сразу же SELinux стал стандартом де-факто защищенной среды Linux и вошел в состав наиболее популярных дистрибутивов: RedHat Enterprise Linux, Fedora, Debian, Ubuntu.

Глоссарий SELinux

LSM и архитектура SELinux

Несмотря на название LSM в общем-то не являются загружаемыми модулями Linux. Однако также, как и SELinux, он непосредственно интегрирован в ядро. Любое изменение исходного кода LSM требует новой компиляции ядра. Соответствующая опция должна быть включена в настройках ядра, иначе код LSM не будет активирован после загрузки. Но даже в этом случае его можно включить опцией загрузчика ОС.

Стек проверок LSM

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

SELinux перенял архитектуру безопасности Flask исследовательской операционной системы Fluke, в частности принцип наименьших привилегий. Суть этой концепции, как следует из их названия, в предоставлении пользователю или процессу лишь тех прав, которые необходимы для осуществления предполагаемых действий. Данный принцип реализован с помощью принудительной типизации доступа, таким образом контроль допусков в SELinux базируется на модели домен => тип.

Благодаря принудительной типизации доступа SELinux имеет гораздо более значительные возможности по разграничению доступа, нежели традиционная модель DAC, используемая в ОС Unix/Linux. К примеру, можно ограничить номер сетевого порта, который будет случать ftp сервер, разрешить запись и изменения файлов в определенной папке, но не их удаление.

Основные компоненты SELinux таковы:

• Policy Enforcement Server — Основной механизм организации контроля доступа.
• БД политик безопасности системы.
• Взаимодействие с перехватчиком событий LSM.
• Selinuxfs — Псевдо-ФС, такая же, как /proc и примонтированная в /sys/fs/selinux. Динамически заполняется ядром Linux во время выполнения и содержит файлы, содержащие сведения о статусе SELinux.
• Access Vector Cache — Вспомогательный механизм повышения производительности.

Схема работы SELinux

Все это работает следующим образом.

1. Некий субъект, в терминах SELinux, выполняет над объектом разрешенное действие после DAC проверки, как показано не верхней картинке. Этот запрос на выполнение операции попадает к перехватчику событий LSM.
2. Оттуда запрос вместе с контекстом безопасности субъекта и объекта передается на модуль SELinux Abstraction and Hook Logic, ответственный за взаимодействие с LSM.
3. Инстанцией принятия решения о доступе субъекта к объекту является Policy Enforcement Server и к нему поступают данные от SELinux AnHL.
4. Для принятия решения о доступе, или запрете Policy Enforcement Server обращается к подсистеме кэширования наиболее используемых правил Access Vector Cache (AVC).
5. Если решение для соответствующего правила не найден в кэше, то запрос передается дальше в БД политик безопасности.
6. Результат поиска из БД и AVC возвращается в Policy Enforcement Server.
7. Если найденная политика согласуется с запрашиваемым действием, то операция разрешается. В противном случае операция запрещается.

Управление настройками SELinux

SELinux работает в одном из трех режимов:

• Enforcing — Строгое соблюдение политик безопасности.
• Permissive — Допускается нарушение ограничений, в журнале делается соответствующая пометка.
• Disabled — Политики безопасности не действуют.

Посмотреть в каком режиме находится SELinux можно следующей командой.

Изменение режима до перезагрузки, например выставить на enforcing, или 1. Параметру permissive соответствует числовой код 0.

Также изменить режим можно правкой файла:

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing — SELinux security policy is enforced.
# permissive — SELinux prints warnings instead of enforcing.
# disabled — No SELinux policy is loaded.
SELINUX=enforcing
# SELINUXTYPE= can take one of three values:
# targeted — Targeted processes are protected,
# minimum — Modification of targeted policy. Only selected processes are protected.
# mls — Multi Level Security protection.

Разница с setenfoce в том, что при загрузке операционный системы режим SELinux будет выставлен в соответствии со значением параметра SELINUX конфигурационного файла. Помимо того, изменения enforcing disabled вступают в силу только через правку файла /etc/selinux/config и после перезагрузки.

Просмотреть краткий статусный отчет:

SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: permissive
Mode from config file: enforcing
Policy MLS status: enabled
Policy deny_unknown status: allowed
Max kernel policy version: 31
Для просмотра атрибутов SELinux некоторые штатные утилиты используют параметр -Z.

По сравнению с обычным выводом ls -l тут есть несколько дополнительных полей следующего формата:

Последнее поле обозначает нечто вроде грифа секретности и состоит из комбинации двух элементов:

• s0 — значимость, также записывают интервалом lowlevel-highlevel
• c0, c1… c1023 — категория.

Изменение конфигурации доступов

Используйте semodule, чтобы загружать модули SELinux, добавлять и удалять их.

Первая команда semanage login связывает пользователя SELinux с пользователем операционной системы, вторая выводит список. Наконец последняя команда с ключом -r удаляет связку отображение пользователей SELinux на учетные записи ОС. Объяснение синтаксиса значений MLS/MCS Range находится в предыдущем разделе.

Login Name SELinux User MLS/MCS Range Service
__default__ unconfined_u s0-s0:c0.c1023 *
root unconfined_u s0-s0:c0.c1023 *
system_u system_u s0-s0:c0.c1023 *
[admin@server

]$ semanage login -d karol

Команда semanage user используется для управления отображений между пользователями и ролями SELinux.

• -a добавить пользовательскую запись соответствия ролей;
• -l список соответствия пользователей и ролей;
• -d удалить пользовательскую запись соответствия ролей;
• -R список ролей, прикрепленных к пользователю;

Файлы, порты и булевы значения

Каждый модуль SELinux предоставляет набор правил маркировки файлов, но также можно добавить собственные правила для в случае необходимости. Например мы желаем дать веб серверу права доступа к папке /srv/www.

Первая команда регистрирует новые правила маркировки, а вторая сбрасывает, вернее выставляет, типы файлов в соответствии с текущими правилами.

Аналогично, TCP/UDP порты отмечены таким образом, что лишь соответствующие сервисы могут их прослушивать. Например, для того, чтобы веб-сервер мог прослушивать порт 8080, нужно выполнить команду.

Значительное число модулей SELinux имеют параметры, которые могут принимать булевы значения. Весь список таких параметров можно увидеть с помощью getsebool -a. Изменять булевы значения можно с помощью setsebool.

Практикум, получить доступ к интерфейсу Pgadmin-web

Рассмотрим пример из практики, мы установили на RHEL 7.6 pgadmin4-web для администрирования БД PostgreSQL. Мы прошли небольшой квест с настройкой pg_hba.conf, postgresql.conf и config_local.py, выставили права на папки, установили из pip недостающие модули Python. Все готово, запускаем и получаем 500 Internal Server error.

Начинаем с типичных подозреваемых, проверяем /var/log/httpd/error_log. Там есть некоторые интересные записи.

[timestamp] [core:notice] [pid 23689] SELinux policy enabled; httpd running as context system_u:system_r:httpd_t:s0
.
[timestamp] [wsgi:error] [pid 23690] [Errno 13] Permission denied: ‘/var/lib/pgadmin’
[timestamp] [wsgi:error] [pid 23690]
[timestamp] [wsgi:error] [pid 23690] HINT : You may need to manually set the permissions on
[timestamp] [wsgi:error] [pid 23690] /var/lib/pgadmin to allow apache to write to it.

На этом месте у большинства администраторов Linux возникнет стойкое искушение запустить setenforce 0, да и дело с концом. Признаться, в первый раз я так и сделал. Это конечно тоже выход, но далеко не самый лучший.

Несмотря на громоздкость конструкций SELinux может быть дружественным к пользователю. Достаточно установить пакет setroubleshoot и просмотреть системный журнал.

]$ yum install setroubleshoot
[admin@server

]$ journalctl -b -0
[admin@server

]$ service restart auditd

Обратите внимание на то, что сервис auditd необходимо перезапускать именно так, а не с помощью systemctl, несмотря на наличие systemd в ОС. В системном журнале будет указан не только факт блокировки, но также причина и способ преодоления запрета.

Выполняем эти команды:

]$ setsebool -P httpd_can_network_connect 1
[admin@server

]$ setsebool -P httpd_can_network_connect_db 1

Проверяем доступ на веб страницу pgadmin4-web, всё работает.

Источник

Уязвимости неуязвимого Linux

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

Фото: Trend Micro

По данным Linux Foundation, ещё в 2017 году под управлением Linux работали 90% клиентских ресурсов у всех облачных провайдеров, причём в девяти из десяти случаев и сам облачный провайдер использовал в качестве основной ОС именно Linux. Но облаками дело не ограничивается: 82% всех выпущенных в мире смартфонов также используют Linux, а среди суперкомпьютеров доля Linux составляет 99%.

По мере того, как предприятия и организации переносят данные в облака, где царит Linux, вектор интереса злоумышленников смещается на слабые места этого семейства операционных систем: уязвимости, неправильные настройки и пробелы в безопасности, а также вредоносное ПО.

Уязвимости

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

Количество критических уязвимостей в различных дистрибутивах за 2015-2020 год. Источник: Trend Micro

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

Каждый производитель дистрибутива Linux выполняет свою процедуру обработки уязвимостей. В то время как исправления от вендоров приходят в разное время, заплатки upstream, будь то оригинальный пакет или исходный код утилиты, появляются первыми. Вендоры Linux отвечают за исправление уязвимостей в таких компонентах, как ядро, утилиты и пакеты. В 2019 году Red Hat исправил более 1000 CVE в своём дистрибутиве Red Hat Enterprise Linux (RHEL), согласно их отчёту Product Security Risk Report. Это более 70% от общего числа уязвимостей, исправленных во всех продуктах.

Количество важных и критических рекомендаций по безопасности для различных дистрибутивов Linux за 2015-2020 годы. Источник: Trend Micro

Уязвимости приложений, работающих под управлением Linux, были причиной нескольких серьёзных инцидентов. Например, нашумевшая утечка данных в Equifax произошла в результате эксплуатации уязвимости CVE-2017-5638 в Apache Struts. Тогда хакеры проникли в корпоративную сеть бюро кредитных историй Equifax 13 мая 2017 года, но подозрительную активность служба безопасности заметила только в конце июля. Киберпреступники провели внутри сети 76 дней, успев за это время скачать из 51 базы данных личную информацию 148 млн американцев — это 56% взрослого населения США. Помимо американских граждан в утечку попали сведения 15 млн клиентов Equifax в Великобритании и около 20 тыс. граждан Канады. Общие расходы Equifax в результате этого инцидента за два следующих года составили более 1,35 млрд долларов США и включают расходы на укрепление систем безопасности, поддержку клиентов, оплату юридических услуг, а также выплаты по судебным искам.

Уязвимости публичных приложений входят в состав фреймворка MITRE ATT&CK (ID T1190), а также перечислены в топ-10 уязвимостей OWASP и являются наиболее популярными векторами проникновения в Linux-системы.

Ошибки конфигурации

Небезопасные настройки довольно распространены и всегда были критическим вопросом в области безопасности. Первая версия OWASP Top 10 Web Risks от 2004 года, включала в себя «Небезопасное управление конфигурацией» (Insecure Configuration Management); в версии списка 2017 года название изменилось на «Ошибочные настройки безопасности» (Security Misconfiguration).

Когда предприятия стали массово переходить на облачные технологии для обеспечения операционной и экономической устойчивости во время пандемии COVID-19, неправильная конфигурация стала ещё более серьёзной проблемой: по мере переезда предприятий и организаций в новые экосистемы они непреднамеренно вносили ошибки в конфигурации облачной инфраструктуры, контейнеров и бессерверных сред.

Ниже перечислены наиболее распространённые проблемы безопасности в конфигурации Linux.

Слабые пароли в Linux как массовое явление

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

Например, в дистрибутивах Debian/Ubuntu время жизни пароля по умолчанию составляет 99 999 дней, а если требуется принудительно задать сложность пароля, придётся устанавливать пакет libpam-pwquality или его аналог.

Настройки времени жизни пароля по умолчанию в Ubuntu (файл /etc/login.defs). Источник: linuxtechi

Известный пример злоупотребления из-за отсутствия аутентификации произошёл в Tesla, когда злоумышленники получили доступ панели управления административной консоли, смогли взломать работающую подсистему Kubernetes и получить AWS-удостоверения Tesla для запуска майнера криптовалюты.

В ноябре 2020 года ФБР выпустило предупреждение о том, что злоумышленники злоупотребляют неправильно настроенными экземплярами SonarQube, который обнаруживает ошибки и уязвимости в безопасности исходного кода. Из-за того, что некоторые организации не поменяли настройки систем по умолчанию, они были доступны через порт 9000 с использованием учётных данных admin/admin.

Такая же проблема массово присутствует среди работающих под управлением Linux IoT-устройств, производители которых часто не утруждают себя безопасными настройками паролей. Многие IP-камеры и роутеры также поставляются без паролей или с паролями по умолчанию, которые можно легко найти в общедоступной базе паролей по умолчанию (Default Passwords Database). Причём в некоторых случаях пароли жёстко прошиты и не могут быть изменены.

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

Развитие специализированных поисковых систем привело к тому, что уязвимый открытый порт в интернете можно расценивать как приглашение к атаке. Например, используя специализированную поисковую систему Shodan, мы обнаружили более 8 тыс. уязвимых экземпляров Redis, размещённых в публичном облаке без TLS-шифрования и даже без пароля. Позже оказалось, что все они уже использовались кем-то для майнинга криптовалюты.

Открытые файловые ресурсы на Linux-серверах

Публично доступные FTP-, SMB- и NFS-ресурсы, разрешённый листинг каталогов на веб-серверах под управлением Linux, открытые облачные службы хранения данных Amazon S3 и Azure Blob создают потенциальный риск несанкционированного доступа. С помощью Shodan мы обнаружили более 3 млн уязвимых публичных FTP-серверов.

Общее количество уязвимых публичных FTP-серверов по состоянию на 5 января 2021 года. Источник: Trend Micro

Вредоносное ПО

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

Ниже перечислены наиболее распространённые типы вредоносных программ в экосистеме Linux.

Вымогатели

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

В качестве примера Linux-вымогателей можно привести RansomEXX/Defray7777, относительно недавно портированный под эту операционную систему. Его применяла кибергруппировка Gold Dupont, атакующая организации из сфер здравоохранения и образование и технологические отрасли.

Другой вымогатель — Erebus, впервые замеченный в сентябре 2016 года, — в июне 2017 года Erebus заразил 153 Linux-сервера южнокорейской хостинговой компании NAYANA и вывел из строя 3400 клиентских сайтов.

Криптомайнеры

Относительно новым мотивом для злоумышленников является проникновение и злоупотребление вычислительными ресурсами для добычи криптовалюты.

Многие вредоносные криптомайнеры не просто заражают Linux-системы, но и очищают их от присутствия майнеров-конкурентов, а также стремятся захватить как можно более мощные системы с практически неограниченными вычислительными возможностями, такие как контейнеры Docker или Redis.

Для проникновения в систему майнеры используют распространённые уязвимости. Например, программа coinminer, детектируемая компанией Trend Micro под названием Coinminer.Linux.MALXMR.SMDSL64, использует уязвимости обхода авторизации SaltStack (CVE-2020-11651) и обхода каталога SaltStack (CVE-2020-11652).

Вредоносные скрипты

Командные интерпретаторы присутствуют на всех UNIX-машинах, поэтому злоумышленники активно используют его, тем более что это значительно проще, чем использовать скомпилированные вредоносные программы.

Причин популярности вредоносных скриптов для атак на Linux:

они легко загружаются в виде текстовых файлов;

они имеют небольшой размер;

меньше вероятность того, что они будут легко обнаружены;

они могут быть созданы «на лету».

Веб-шеллы и бэкдоры

Веб-шелл — установленный на веб-сервере скрипт, который выполняет команды преступника и обеспечивает ему прямой доступ к взломанной системе. Например, в августе 2020 года мы столкнулись с Ensiko, веб-оболочкой PHP, нацеленной на Linux, Windows, macOS или любую другую платформу, на которой установлен PHP. Помимо удалённого выполнения кода с помощью Ensiko злоумышленники могут выполнять команды оболочки и повреждать веб-сайты.

Руткиты

Руткит — набор вредоносных программ, которые внедряются в Linux-систему, частично или полностью подменяя стандартные системные утилиты, драйверы и библиотеки. Основная цель руткита — скрывать своё присутствие от администраторов и пользователей скомпрометированной системы, обеспечивая злоумышленнику полный или частичный контроль.

В ходе наших исследований мы сталкивались с несколькими семействами руткитов. Чаще всего это были Umbreon, Drovorub или Diamorphine.

Рекомендации

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

Вот несколько рекомендаций по обеспечению безопасности систем Linux:

внедрите в качестве обязательного принцип «Инфраструктура как код» (Infrastructure as Code, IaC), который гарантирует что системы создаются должным образом, а их конфигурации соответствуют решаемым задачам;

используйте принцип наименьших привилегий и модель совместной ответственности;

контролируйте целостность операционной системы, чтобы подозрительные изменения не могли произойти незаметно;

отслеживайте сетевой периметр, проводите мониторинг всех устройств, систем и сетей;

замените пароли по умолчанию на сильные и безопасные, по возможности всегда включайте многофакторную аутентификацию;

регулярно устанавливайте обновления и исправления ошибок.

Источник