Введение в SELinux модификация политики targeted для сторонних веб-приложений dump credit card sites, best airline cc
Статья о методологии настройки SELinux для веб-серверов от Кирилла Ермакова, исследовательский центр Positive Research
Многие из нас занимаются настройкой рабочих серверов для веб-проектов. Я не буду рассказывать о том, как настроить Apache или Nginx: вы знаете об этом больше меня. Но один важный аспект создания frontend-серверов остается неосвещенным: это настройки подсистем безопасности. «Отключите SELinux» , — вот стандартная рекомендация большинства любительских руководств. Мне кажется, что это поспешное решение, ибо процесс настройки подсистем безопасности в режиме «мягкой» политики чаще всего весьма тривиален.
Сегодня я расскажу вам о некоторых методах настройки подсистемы безопасности SELinux, применяемой в семействе операционных систем Red Hat (CentOS). В качестве примера мы настроим связку для веб-сервера Apache + mod_wsgi + Django + ZEO на CentOS версии 5.8.
При настройке систем безопасности Linux мы скованы рамками системы избирательного управления доступом (Discretionary Access Control, DAC). В нашем распоряжении стандартные права rwx на трех уровнях (владелец, группа-владелец и остальные) и POSIX ACL. Таким образом, приложение с правами user теоретически имеет доступ ко всем ресурсам, доступным соответствующему пользователю. В случае компрометации приложения это может привести к печальным последствиям.
SELinux (Security-Enhanced Linux) — это подсистема безопасности, которая реализует мандатное управление доступом (Mandatory Access Control, MAC), работающее параллельно с классической дискреционной системой. Права доступа при этом определяются системой при помощи политик. В семействе операционных систем Red Hat (CentOS) вы получаете SELinux «из коробки», в качестве части ядра. Для простейшего решения поставленных задач нам потребуется политика targeted («целевая»), в рамках которой описаны правила для основной массы типовых приложений. Мы получаем базовую защиту основных сервисов без дополнительных усилий. Правила политики таковы, что все не описанные в ней приложения будут работать без ограничений со стороны SELinux в рамках DAC.
«Но зачем, собственно, нам нужен этот SELinux?» — спросите вы. Ответ довольно прост: в ряде случаев подсистема безопасности позволит как минимум запротоколировать несанкционированный доступ, а в идеале — предотвратить его. В любом случае, нарушителю придется действовать в рамках, очерченных для конкретного процесса.
Для добавления собственных настроек мы будем оперировать контекстами, доменами и векторами доступа. События, имеющие значение с точки зрения безопасности, перехватываются SELinux на уровне ядра. Механизмы подсистемы безопасности вступают в действие после правил DAC. SELinux предоставляет возможности RBAC (Role-Based Access Control), TE (Type Enforcement) и, опционально, MLS (Multi-Level Security). Каждый объект системы имеет определенный контекст (тип). На основе правил политики подсистема безопасности либо позволяет выполнение данной операции, либо блокирует его, — и процесс получает сообщение об ошибке. Все принятые SELinux решения кэшируются в Access Vector Cache (AVC).
Контекст SELinux содержит информацию о пользователе, роли, типе и уровне. Мы будем оперировать типом, являющимся атрибутом Type Enforcement. Он определяетcя доменом для процессов и типом для файлов. В правилах SELinux описаны разрешенные типы взаимодействия. Доступ разрешается только в случае наличия соответствующего правила.
Отдельно хотелось бы отметить технологию доменных переходов. В SELinux переход приложения из одного домена в другой возможен, если процесс из исходного домена выполняет приложение, которое запускается из файла с типом entrypoint нового домена.
В стандартной политике targeted созданы и описаны контексты, домены и правила доступа более чем для 200 приложений. Вы имеете возможность как расширить политику, так и действовать в рамках предложенных контекстов. При разработке базовых политик были учтены практически все основные сценарии использования. Для создания типовых решений вам практически ничего не придется менять.
Итак, при реализации шаблонных решений отказ от использования защитного механизма SELinux по меньшей мере не обоснован. Отдельные трудности при его использовании возникают при установке дополнительного программного обеспечения. В контексте поставленной задачи таковыми являются модуль mod_wsgi и ZEO. Для сохранения работоспособности SELinux нам потребуется внести изменения в его настройки.
В своем примере я использую CentOS 5.8 (kernel 2.6.18-308.1.1.el5) с веб-сервером Apache (httpd-2.2.3-63.el5.centos.1). На него дополнительно установлены из исходных кодов Python (2.7.2), Django (1.4), mod_wsgi (3.3) и Zope (3.4.0). (Прозаичный процесс установки данного программного обеспечения не заслуживает отдельного описания.)
Прежде всего нам потребуется расширить политику SELinux для httpd. Настройки по умолчанию предназначены для надежной изоляции процесса в случае его компрометации. Однако для доступа httpd к вашему проекту потребуется внести некоторые изменения. Авторами политики заложена полная логика работы приложения с ограничениями по контексту. Ознакомиться с разметкой файлов в вашей системе поможет простая команда:
Политика регламентирует доступ к каждому из представленных типов. Ознакомиться с полным перечнем контекстов можно на соответствующей man-странице (man httpd_selinux). Нас интересует тип httpd_sys_content_t, который разрешает демону и сценариям доступ к файлам. Таким образом, помимо стандартных прав DAC необходимо задать контекст директории и файлов вашего проекта. Это можно сделать единовременно при помощи команды chcon.
chcon -R -t /your/project
Однако я рекомендую задать тип при помощи правила. Это обеспечит последующее автоматическое присвоение типа при добавлении новых файлов.
semanage fcontext -a -t httpd_sys_content_t “/your/project(/.*)?”
restorecon -R /your/project
Мой демонстрационный проект использует Django с базой данных ZoDB. В качестве средства для коммуникации с БД используется ZEO. Так как это самостоятельное ПО, необходимо обеспечить его функционирование в рамках SELinux. Для обеспечения изоляции целесообразно, как я полагаю, осуществить запуск ZEO с правами пользователя apache в домене httpd_t. Для этого определим сценарий инициализации запуска в режиме демона. Я не стану приводить здесь листинг всего сценария ввиду его большого размера. Нам будет достаточно главного:
/usr/local/bin/zeoctl -d -s /var/run/zeo/zsock -C /etc/zeo/zeoctl.conf start
Не стоит забывать, что ваш сценарий инициализации необходимо привести к соответствующему контексту для отсутствия проблем при последующем переходе типов в SELinux.
chcon –t “initrc_exec_t” /etc/init.d/your_init_script
В конфигурационном файле необходимо указать необходимого пользователя.
<runner>
program /usr/local/bin/runzeo -a /var/run/zeo/zeo.socket -f /var/your_db_path/db.fs
daemon True
user apache
</runner>
В качестве связующего звена между ZEO и Django используется сокет. Поскольку httpd работает в домене httpd_t, необходимо согласовать типы и DAC-права таким образом, чтобы приложение могло к нему подключиться. Для этого мы подготовим директорию /var/run/zeo и зададим для нее необходимый контекст. Мы используем ключ -f -s, для того чтобы ограничить автоматическое присвоение контекста только сокетами, а также -f -d — чтобы контекст установился на директорию.
semanage fcontext -a -f -d -t ‘httpd_sys_script_rw_t’ ‘/var/run/zeo(/.*)?’
semanage fcontext -a -f -s -t ‘httpd_sys_script_rw_t’ ‘/var/run/zeo(/.*)?’
restorecon –R /var/run
В конфигурационном файле ZEO необходимо указать принудительное расположение коммуникационного сокета.
<zeo>
address /var/run/zeo/zeo.socket
</zeo>
Поскольку мы планируем запуск приложения от имени пользователя apache, необходимо учесть транзитивность типов. Нам нужно, чтобы запущенный процесс получил тип httpd_t. По умолчанию файлы /usr/local/bin/zeoctl и /usr/local/bin/runzeo будут иметь контекст bin_t. Поскольку они будут вызываться из домена unconfined_t, то необходимо проследить цепочку переходов контекстов. Прежде всего будет вызван сценарий из /etc/init.d/, которому мы присвоили тип initrc_exec_t. Найдем цепочку переходов для этой ситуации.
sesearch -T -s unconfined_t -t initrc_exec_t | grep ” initrc_exec_t”
Найденная цепочка перехода выглядит как unconfined_t initrc_exec_t: process initrc_t. Мы видим, что процесс получит контекст initrc_t. Соответственно, теперь нам нужно обнаружить цепочку переходов, которая приведет нас к необходимому типу httpd_t.
sesearch -T -s initrc_t | grep “process httpd_t”
Результатом поиска будет связь initrc_t httpd_exec_t: process httpd_t. Для того чтобы произошел данный переход, нам следует установить контекст httpd_exec_t на исполняемые файлы.
semanage fcontext -a -t httpd_exec_t “/usr/local/bin/zeoctl”
semanage fcontext -a -t httpd_exec_t “/usr/local/bin/runzeo”
restorecon -R /usr/local/bin
Теперь нам нужно добавить в политику SELinux разрешения на подключение к сокету для httpd. Это можно сделать несколькими способами. Самый простой с точки зрения пользователя — это утилита audit2allow, позволяющая формировать модули для политики на основе AVC-сообщений из системных журналов. Пользоваться утилитой следует осторожно, поскольку она лишь создает разрешения для определенных действий — но не более того ( подробное руководство представлено на сайте разработчиков ).
Вторым путем будет создание модуля вручную, его компиляция и установка в текущую политику. Поскольку данный способ дает лучшую визуализацию процесса, мы изготовим модули для ZEO именно так. Предоставим httpd_t права на создание и работу с сокетом, имеющим тип httpd_sys_script_rw_t. Для этого создадим файл /tmp/httpdAllowDjangoZEO.te со следующим содержанием:
module httpdAllowDjangoZEO 1.0;
require {
type httpd_t;
type httpd_sys_script_rw_t;
class sock_file link;
class sock_file setattr;
class sock_file create;
class sock_file unlink;
class sock_file write;
}
#============= httpd_t ==============
allow httpd_t httpd_sys_script_rw_t:sock_file link;
allow httpd_t httpd_sys_script_rw_t:sock_file setattr;
allow httpd_t httpd_sys_script_rw_t:sock_file create;
allow httpd_t httpd_sys_script_rw_t:sock_file unlink;
allow httpd_t httpd_sys_script_rw_t:sock_file write;
Далее нам необходимо создать и скомпилировать модуль. Для этого воспользуемся командами checkmodule и semodule_package. Для инсталляции модуля в текущую политику нам потребуется утилита semodule.
checkmodule -M -m -o /tmp/httpdAllowDjangoZEO.mod /tmp/httpdAllowDjangoZEO.te
semodule_package –outfile /tmp/httpdAllowDjangoZEO.pp –module /tmp/httpdAllowDjangoZEO.mod
semodule -i httpdAllowDjangoZEO.pp
Финальным действием будет настройка контекстов места хранения базы данных ZoDB и конфигурационного файла ZEO. Нам в процессе работы потребуется создавать технические файлы .lock. Следовательно, место хранения БД необходимо разметить соответствующим контекстом, который будет позволять создание файлов. Для этого хорошо подойдет «httpd_sys_script_rw_t».
semanage fcontext –a –t «httpd_sys_script_rw_t» “/var/your_db_path(/.*)?”
Для конфигурационных файлов существует специализированный тип «httpd_config_t».
semanage fcontext –a –t « httpd_config_t» “/etc/zeo(/.*)?”
Теперь достаточно перезапустить сервисы для окончания процесса настройки.
Написанные нами правила позволят всей связке работать без проблем. При этом мы обеспечиваем сервер и его службы дополнительной защитой SELinux. В случае компрометации какого-либо из компонентов Django или ZEO злоумышленник будет ограничен и не сможет добраться до системы, поскольку будет действовать в рамках домена httpd_t.
Итак, мы получили работоспособную пользовательскую конфигурацию httpd без отключения SELinux. Подобным образом вы можете создать регламентирующие политики для любого из ваших приложений. Это не занимает много времени и не требует серьезной теоретической подготовки. Так может быть не стоит отключать SELinux?
Для более целостного понимания технологии SELinux я рекомендую вам ознакомиться с русскоязычным описанием SELinux для Fedora 13 .
В статье мы расскажем о наиболее интересных стартапах в области кибербезопасности, на которые следует обратить внимание.
Хотите узнать, что происходит нового в сфере кибербезопасности, – обращайте внимание на стартапы, относящиеся к данной области. Стартапы начинаются с инновационной идеи и не ограничиваются стандартными решениями и основным подходом. Зачастую стартапы справляются с проблемами, которые больше никто не может решить.
Обратной стороной стартапов, конечно же, нехватка ресурсов и зрелости. Выбор продукта или платформы стартапа – это риск, требующий особых отношений между заказчиком и поставщиком . Однако, в случае успеха компания может получить конкурентное преимущество или снизить нагрузку на ресурсы безопасности.
Ниже приведены наиболее интересные стартапы (компании, основанные или вышедшие из «скрытого режима» за последние два года).
Компания Abnormal Security, основанная в 2019 году, предлагает облачную платформу безопасности электронной почты, которая использует анализ поведенческих данных для выявления и предотвращения атак на электронную почту. Платформа на базе искусственного интеллекта анализирует поведение пользовательских данных, организационную структуру, отношения и бизнес-процессы, чтобы выявить аномальную активность, которая может указывать на кибератаку. Платформа защиты электронной почты Abnormal может предотвратить компрометацию корпоративной электронной почты, атаки на цепочку поставок , мошенничество со счетами, фишинг учетных данных и компрометацию учетной записи электронной почты. Компания также предоставляет инструменты для автоматизации реагирования на инциденты, а платформа дает облачный API для интеграции с корпоративными платформами, такими как Microsoft Office 365, G Suite и Slack.
Копания Apiiro вышла из «скрытого режима» в 2020 году. Ее платформа devsecops переводит жизненный цикл безопасной разработки «от ручного и периодического подхода «разработчики в последнюю очередь» к автоматическому подходу, основанному на оценке риска, «разработчики в первую очередь», написал в блоге соучредитель и генеральный директор Идан Плотник . Платформа Apiiro работает, соединяя все локальные и облачные системы управления версиями и билетами через API. Платформа также предоставляет настраиваемые предопределенные правила управления кодом. Со временем платформа создает инвентарь, «изучая» все продукты, проекты и репозитории. Эти данные позволяют лучше идентифицировать рискованные изменения кода.
Axis Security Application Access Cloud – облачное решение для доступа к приложениям , построенное на принципе нулевого доверия. Он не полагается на наличие агентов, установленных на пользовательских устройствах. Поэтому организации могут подключать пользователей – локальных и удаленных – на любом устройстве к частным приложениям, не затрагивая сеть или сами приложения. Axis вышла из «скрытого режима» в 2020 году.
BreachQuest, вышедшая из «скрытого режима» 25 августа 2021 года, предлагает платформу реагирования на инциденты под названием Priori. Платформа обеспечивает большую наглядность за счет постоянного отслеживания вредоносной активности. Компания утверждает, что Priori может предоставить мгновенную информацию об атаке и о том, какие конечные точки скомпрометированы после обнаружения угрозы.
Cloudrise предоставляет услуги управляемой защиты данных и автоматизации безопасности в формате SaaS. Несмотря на свое название, Cloudrise защищает как облачные, так и локальные данные. Компания утверждает, что может интегрировать защиту данных в проекты цифровой трансформации. Cloudrise автоматизирует рабочие процессы с помощью решений для защиты данных и конфиденциальности. Компания Cloudrise была запущена в октябре 2019 года.
Cylentium утверждает, что ее технология кибер-невидимости может «скрыть» корпоративную или домашнюю сеть и любое подключенное к ней устройство от обнаружения злоумышленниками. Компания называет эту концепцию «нулевой идентичностью». Компания продает свою продукцию предприятиям, потребителям и государственному сектору. Cylentium была запущена в 2020 году.
Компания Deduce , основанная в 2019 году, предлагает два продукта для так называемого «интеллектуального анализа личности». Служба оповещений клиентов отправляет клиентам уведомления о потенциальной компрометации учетной записи, а оценка риска идентификации использует агрегированные данные для оценки риска компрометации учетной записи. Компания использует когнитивные алгоритмы для анализа конфиденциальных данных с более чем 150 000 сайтов и приложений для выявления возможного мошенничества. Deduce заявляет, что использование ее продуктов снижает ущерб от захвата аккаунта более чем на 90%.
Автоматизированная платформа безопасности и соответствия Drata ориентирована на готовность к аудиту по таким стандартам, как SOC 2 или ISO 27001. Drata отслеживает и собирает данные о мерах безопасности, чтобы предоставить доказательства их наличия и работы. Платформа также помогает оптимизировать рабочие процессы. Drata была основана в 2020 году.
FYEO – это платформа для мониторинга угроз и управления доступом для потребителей, предприятий и малого и среднего бизнеса. Компания утверждает, что ее решения для управления учетными данными снимают бремя управления цифровой идентификацией. FYEO Domain Intelligence («FYEO DI») предоставляет услуги мониторинга домена, учетных данных и угроз. FYEO Identity будет предоставлять услуги управления паролями и идентификацией, начиная с четвертого квартала 2021 года. FYEO вышла из «скрытого режима» в 2021 году.
Kronos – платформа прогнозирующей аналитики уязвимостей (PVA) от компании Hive Pro , основанная на четырех основных принципах: предотвращение, обнаружение, реагирование и прогнозирование. Hive Pro автоматизирует и координирует устранение уязвимостей с помощью единого представления. Продукт компании Artemis представляет собой платформу и услугу для тестирования на проникновение на основе данных. Компания Hive Pro была основана в 2019 году.
Израильская компания Infinipoint была основана в 2019 году. Свой основной облачный продукт она называет «идентификация устройства как услуга» или DIaaS , который представляет собой решение для идентификации и определения положения устройства. Продукт интегрируется с аутентификацией SSO и действует как единая точка принуждения для всех корпоративных сервисов. DIaaS использует анализ рисков для обеспечения соблюдения политик, предоставляет статус безопасности устройства как утверждается, устраняет уязвимости «одним щелчком».
Компания Kameleon , занимающаяся производством полупроводников, не имеет собственных фабрик и занимает особое место среди поставщиков средств кибербезопасности. Компания разработала «Блок обработки проактивной безопасности» (ProSPU). Он предназначен для защиты систем при загрузке и для использования в центрах обработки данных, управляемых компьютерах, серверах и системах облачных вычислений. Компания Kameleon была основана в 2019 году.
Облачная платформа безопасности данных Open Raven предназначена для обеспечения большей прозрачности облачных ресурсов. Платформа отображает все облачные хранилища данных, включая теневые облачные учетные записи, и идентифицирует данные, которые они хранят. Затем Open Raven в режиме реального времени отслеживает утечки данных и нарушения политик и предупреждает команды о необходимости исправлений. Open Raven также может отслеживать файлы журналов на предмет конфиденциальной информации, которую следует удалить. Компания вышла из «скрытого режима» в 2020 году.
Компания Satori, основанная в 2019 году, называет свой сервис доступа к данным “DataSecOps”. Целью сервиса является отделение элементов управления безопасностью и конфиденциальностью от архитектуры. Сервис отслеживает, классифицирует и контролирует доступ к конфиденциальным данным. Имеется возможность настроить политики на основе таких критериев, как группы, пользователи, типы данных или схема, чтобы предотвратить несанкционированный доступ, замаскировать конфиденциальные данные или запустить рабочий процесс. Сервис предлагает предварительно настроенные политики для общих правил, таких как GDPR , CCPA и HIPAA .
Компания Scope Security недавно вышла из «скрытого режима», будучи основана в 2019 году. Ее продукт Scope OmniSight нацелен на отрасль здравоохранения и обнаруживает атаки на ИТ-инфраструктуру, клинические системы и системы электронных медицинских записей . Компонент анализа угроз может собирать индикаторы угроз из множества внутренних и сторонних источников, представляя данные через единый портал.
Основным продуктом Strata является платформа Maverics Identity Orchestration Platform . Это распределенная мультиоблачная платформа управления идентификацией. Заявленная цель Strata – обеспечить согласованность в распределенных облачных средах для идентификации пользователей для приложений, развернутых в нескольких облаках и локально. Функции включают в себя решение безопасного гибридного доступа для расширения доступа с нулевым доверием к локальным приложениям для облачных пользователей, уровень абстракции идентификации для лучшего управления идентификацией в мультиоблачной среде и каталог коннекторов для интеграции систем идентификации из популярных облачных систем и систем управления идентификацией. Strata была основана в 2019 году.
SynSaber , запущенная 22 июля 2021 года, предлагает решение для мониторинга промышленных активов и сети. Компания обещает обеспечить «постоянное понимание и осведомленность о состоянии, уязвимостях и угрозах во всех точках промышленной экосистемы, включая IIoT, облако и локальную среду». SynSaber была основана бывшими лидерами Dragos и Crowdstrike.
Traceable называет свой основной продукт на основе искусственного интеллекта чем-то средним между брандмауэром веб-приложений и самозащитой приложений во время выполнения. Компания утверждает, что предлагает точное обнаружение и блокирование угроз путем мониторинга активности приложений и непрерывного обучения, чтобы отличать обычную активность от вредоносной. Продукт интегрируется со шлюзами API. Traceable была основана в июле 2020 года.
Компания Wiz, основанная командой облачной безопасности Microsoft, предлагает решение для обеспечения безопасности в нескольких облаках, рассчитанное на масштабную работу. Компания утверждает, что ее продукт может анализировать все уровни облачного стека для выявления векторов атак с высоким риском и обеспечивать понимание, позволяющее лучше расставлять приоритеты. Wiz использует безагентный подход и может сканировать все виртуальные машины и контейнеры. Wiz вышла из «скрытого режима» в 2020 году.
Работает на CMS “1С-Битрикс: Управление сайтом”
dump credit card sites best airline cc