Как установить брандмауэр csf на centos 7

Методы управления доступом

В большинстве операционных систем имеются средства управления доступом, которые определяют, может ли определенный объект (пользователь или программа) получить доступ к определенному ресурсу. В системах UNIX применяется
разграничительный контроль доступа (discretionary access control, DAC). Этот метод позволяет ограничить доступ к объектам на основе групп, к которым они принадлежат. Например, в GNU/Linux для каждого файла определены владелец, группа, а также указаны права доступа к этому файлу. Правами доступа определяется, кто может получить доступ к файлу, кто может открыть его для чтения, кто может внести в него изменения, кто может запустить этот файл на выполнение. Права доступа определены для трех категорий: пользователь (владелец файла), группа (все пользователи, которые являются членами группы) и другие (все пользователи, которые не являются ни владельцем файла, ни членами группы).

Такое разграничение прав доступа может привести к возникновению ряда проблем из-за того, что программа, в которой может быть обнаружена уязвимость, наследует все права доступа пользователя. Следовательно, она может выполнять действия с тем же уровнем привилегий, какой есть у пользователя (что нежелательно). Вместо того чтобы определять ограничения подобным образом, более безопасно использовать принцип наименьшего уровня привилегий (principle of least privilege), согласно которому программы могут делать только то, что им необходимо для выполнения своих задач, и не более того. Например, если у вас есть программа, задача которой состоит в приеме запросов через сокеты, при этом ей не нужно иметь доступ к файловой системе, то такая программа будет иметь возможность только прослушивать определенный сокет и не будет иметь доступа к файловой системе. Таким образом, даже если в программе будет обнаружена уязвимость, то возможности доступа данной программы будет жестко ограничены. Такой тип контроля называется принудительным управлением доступом (mandatory access control, MAC).

Другим методом управления доступом является управление доступом на основе ролей (role-based access control, RBAC). При использовании RBAC права доступа предоставляются на основе ролей, выдаваемых системой безопасности. Отличие концепции ролей от традиционных групп состоит в том, что группа представляет одного или нескольких пользователей, в то время как роль, хотя она также может быть применена к нескольким пользователям, представляет совокупность полномочий на выполнение определенных действий.

SELinux добавляет в операционную систему GNU/Linux поддержку как MAC, так и RBAC. В следующем разделе рассказывается о реализации SELinux, а также о том, как было прозрачным образом произведено усиление защиты ядра Linux.

Внутренняя архитектура SELinux

В самом начале своего появления SELinux была реализована в виде патча. В данном случае было непросто настраивать политику безопасности. С появлением механизмов LSM, настройка и управление безопасностью значительно упростились (политика и механизмы усиления безопасности были разделены), SELinux была реализована в виде подгружаемых модулей ядра. Перед доступом к внутренним объектам операционной системы производится изменение кода ядра. Это реализуется при помощи специальных функций (перехватчиков системных вызовов), так называемых функций «хуков» (англ. hook functions). Функции-перехватчики хранятся в некоторой структуре данных, их целью является выполнение определенных действий по обеспечению безопасности, основанных на заранее установленной политике. Сам модуль включает в себя шесть главных компонентов: сервер безопасности; кэш вектора доступа (англ. Access Vector Cache, AVC); таблицы сетевых интерфейсов; код сигнала сетевого уведомления; свою виртуальную файловую систему (selinuxfs) и реализацию функций-перехватчиков.

Кэш вектора доступа используется для кэширования вычисленных результатов (хранения готовых решений управления доступом), полученных из сервера безопасности. Нужно это для того, чтобы минимизировать накладные расходы на производительность со стороны механизмов безопасности SELinux. Интерфейс кэша вектора доступа для сервера безопасности определен в заголовочном файле include/avc_ss.h.

Таблица сетевых интерфейсов отображает сетевые устройства в контексты безопасности. Поддержка отдельных таблиц необходима ввиду того, что поле безопасности сетевых устройств было исключено из проекта. Сетевые устройства добавляются в таблицу, когда впервые оказываются в поле видимости функций-перехватчиков (засекаются ими) и удаляются из неё, когда устройство настраивается или перезагружается политика безопасности в связи с перенастройкой. Это возможно благодаря callback-функциям, которые регистрируют изменения конфигурации устройства и перезагрузку политик безопасности. Код таблицы сетевых интерфейсов можно найти в файле netif.c.

Код события сетевого уведомления позволяет модулю SELinux уведомлять процессы операционной системы в случае, когда политика безопасности была перезагружена. Эти уведомления используются пространством пользователя для поддержки совместимости с ядром. Этот механизм возможен благодаря библиотеке SELinux. Код события сетевого уведомления можно найти в файле netlink.c.

Псевдофайловая система SELinux экспортирует API-функции политики сервера безопасности в процессы операционной системы. Изначально API-функции ядра SELinux были разделены на три компонента (атрибуты процесса, файловые атрибуты, политика API) как часть изменений для внесения в версию ядра Linux 2.6. Также SELinux предоставляет поддержку политики API вызовов. Все три компонента API нового ядра инкапсулированы в библиотеку API SELinux (libselinux). Код псевдофайловой системы можно найти в файле selinuxfs.c.

Реализация функций перехватчиков управляет информационной безопасностью связанной с внутренними объектами ядра и реализацией контроля доступа SELinux для каждой операции внутри ядра. Функции перехватчики вызывают сервер безопасности и кэш вектора доступа для получения решений политики безопасности и применения этих решений для маркировки по каким-либо признакам и контроля объектов ядра. Код этих функций перехватчиков расположен в файле hooks.c, а структуры данных, связанные с внутренними объектами, определены в файле include/objsec.h.

Зачем это нужно?

Создатели UNIX наделили свою ОС простым, но весьма гибким и красивым механизмом безопасности. В его основе лежат всем нам известные права доступа на файлы, которые определяют круг лиц (пользователей, процессов), способных выполнять какие-либо действия над файлами и каталогами. Например, мы можем создать исполняемый файл и выставить на него права доступа «-rwxr-xr-x», что будет означать, что мы (то есть владелец файла) можем делать с ним все что захотим, пользователи, входящие в нашу группу, могут его читать и исполнять, а все остальные — только исполнять. Учитывая тот факт, что все устройства в UNIX представлены файлами, такой механизм позволяет не только четко разграничивать доступ пользователей (их приложений) к информации, но и к устройствам и даже к некоторым функциями операционной системы (procfs и sysfs).

Однако, у механизма прав доступа есть два серьезных недостатка. Во-первых, их реализация слишком топорна. Она хорошо подходит для отделения процессов от конфиденциальной информации пользователей, но абсолютно не подходит для гибкого управления их возможностями. Например, чтобы дать какой-либо дисковой утилите (cfdisk, например) возможность модификации хранящейся на диске информации, мы можем либо разрешить полный доступ к диску группе, к которой принадлежит ее владелец, либо запустить ее с правами пользователя root. Как в первом, так и во втором случае мы создадим потенциальную брешь в безопасности: все остальные пользователи/приложения группы получат права доступа к диску, или сама утилита получит наивысшие и безграничные права в системе. А что если нужно дать доступ не к модификации диска, а только к вызову определенных его функций (ioctl)? Здесь права доступа вообще не помогут.

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

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

Обзор LSM

LSM (англ. Linux Security Modules — модули безопасности Linux) представляют собой реализацию в виде подгружаемых модулей ядра. В первую очередь, LSM применяются для поддержки контроля доступа. Сами по себе LSM не обеспечивают систему какой-то дополнительной безопасностью, а лишь являются неким интерфейсом для её поддержки. Система LSM обеспечивает реализацию функций перехватчиков, которые хранятся в структуре политик безопасности, охватывающей основные операции, защиту которых необходимо обеспечить. Контроль доступа в систему осуществляется благодаря настроенным политикам.

Методы управления доступом

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

Дискреционный контроль доступа (англ. Discretionary Access Control, DAC). Данный метод реализует ограничение доступа к объектам на основе групп, к которым они принадлежат. В Linux, в основе этого метода, лежит стандартная модель контроля доступа к файлам. Права доступа определены для следующих категорий: пользователь (владелец файла), группа (все пользователи, которые являются членами группы), другие (все пользователи, которые не являются ни владельцами файла, ни членами группы). Причем к каждой из групп предоставляются следующие права: права на запись, на чтение и на исполнение.

Мандатное управление доступом (англ. Mandatory Access Control, MAC). Главным образом суть этого метода заключается в установлении определенных прав доступа субъекта к определенным объектам. В ОС реализовано следующее: программа обладает только теми возможностями, которые необходимы ей для выполнения своих задач, и не более того. Данный метод имеет преимущество в сравнении с предыдущим; если в программе будет обнаружена уязвимость, то возможности её доступа будут весьма ограничены.

Контроль доступа на основе ролей (англ. Role-Based Access Control, RBAC). Права доступа реализованы в виде ролей, выдаваемых системой безопасности. Роли представляют собой определенные полномочия на выполнение конкретных действий группой субъектов над объектами в системе. Данная политика является улучшением дискреционного контроля доступа.

Традиции UNIX

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

Модель безопасности UNIX довольно проста. В основе её лежит
дискреционный механизм доступа — каждый объект в системе
имеет владельца, который и устанавливает права доступа к объекту. Сами
пользователи в системе фигурируют в виде процессов — программ, запущенных
от их имени. Так как в операционной системе UNIX даже устройства
представляются в виде файлов, достаточно для каждого из них хранить
владельца и права на использование этого файла другими пользователями
системы.

Но в операционной системе могут работать тысячи пользователей (а такая
ситуация встречается и сейчас — на мэйнфреймах и других больших машинах).
При этом списки доступа (ACL, Access Control List) для каждого файла
разрастутся до гигантских размеров. Частично эту проблему решает
добавление групп пользователей, но ведь их число тоже может быть
очень большим. Создатели UNIX придумали более элегантное решение: для
каждого файла задаются три группы прав — права владельца, права
группы владельца и права для всех остальных. Таким
образом, все права на файл занимают лишь несколько байт.

В UNIX существует три основных права доступа: чтение, запись и исполнение.
Если права чтения и записи очевидны и понятны, то право исполнения
трактуется по-разному для разных типов файлов. Для простых файлов оно
определяет возможность запуска содержащейся в нём программы. В
UNIX исполняемые файлы могут иметь не только любое расширение (часто они
вообще не имеют в имени символа точки), но и содержимое — это может быть
откомпилированная для данной архитектуры программа или скрипт на любом из
поддерживаемых языков программирования. А вот для директории право
исполнения означает возможность «войти» в неё.

Рисунок 1. Права доступа в
UNIX

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

Другие системы

SELinux представляет один из нескольких возможных подходов к ограничению действий, выполняемых установленным ПО.

Эти различия проявляются в двух случаях:

  • если файл имеет вторую, незащищенную жёсткую ссылку, то AppArmor разрешит доступ через нее, а SELinux откажет, так как жёсткие ссылки ссылаются на один и тот же индексный дескриптор
  • если же приложение пересоздает защищенный файл, что используется довольно часто и приводит к изменению индексного дескриптора, то AppArmor продолжит отказывать в доступе, а SELinux его разрешит

Избежать этих проблем в обеих системах позволит применение политики «no access» по умолчанию.

Подключение nextcloud как сетевой диск

Мы можем подключить пользовательские данные nextcloud в качестве сетевого диска. Рассмотрим процесс для Windows.

Для начала необходимо включить службу «Веб-клиент». Для этого открываем от администратора командную строку и вводим команды:

sc config webclient start= auto

net start webclient

* первая команда включит автозапуск службы; вторая — запустит ее.

После открываем командную строку от пользователя и создаем сетевой диск командой:

net use <Буква диска>: https://<путь до nextcloud>/remote.php/webdav /user:user password

Например, для нашей настройки:

net use N: https://nextcloud.dmosk.ru/remote.php/webdav /user:admin password

* где N — буква сетевого диска; nextcloud.dmosk.ru — адрес нашего сервера; admin — учетная запись, которая была создана при установке системы; password — пароль от пользователя admin.

Установка типов контекста

  • semanage: это команда, которую вы должны использовать. Команда semanage записывает новый контекст в политику SELinux, из которой он применяется к файловой системе.
  • chcon: эта команда предназначена для использования только в определенных случаях и обычно ее следует избегать. Команда chcon записывает новый контекст в файловую систему, а не в политику. Все, что применяется с chcon, перезаписывается, когда файловая система перемаркируется (relabel), или исходный контекст восстанавливается из политики в файловую систему. Не используйте эту команду!

Команда semanage может бытьне установлена по умолчанию. Введите yum whatprovides * / semanage, чтобы найти нужный пакет RPM, содержащий semanage, а затем установите его.
semanagels -Z /var/www

-a-t

Команда semanage — не самая простая команда для запоминания. К счастью, у неё есть хорошие справочные страницы. Введите man semanage и используйте G, чтобы пройти до конца страницы. Теперь вы увидите раздел «see also», в котором упоминается semanage-fcontext. Откройте эту справочную страницу, используя man semanage-fcontext, введите /examples, и вы увидите несколько примеров, в которых точно указано, что вам нужно знать.

Пример. Настройка меток контекста в Nondefault Apache Document Root.

yum install httpd elinks –ymkdir /webvi /web/index.htmlvi /etc/httpd/conf/httpd.conf

systemctl restart httpd; systemctl enable httpdelinks http://localhostsetenforce 0permissivesemanage fcontext -a -t httpd_sys_content_t «/web (/.*)?»restorecon -R -v /web-vsetenforce 1elinks http://localhost

Настройка сервера баз данных

В качестве СУБД используем MariaDB.

Устанавливаем:

dnf install mariadb-server

Разрешаем автозапуск и стартуем сервис:

systemctl enable mariadb —now

Задаем пароль для суперпользователя mysql:

mysqladmin -u root password

Подключаемся к MariaDB, создаем базу данных и пользователя:

mysql -uroot -p

> CREATE DATABASE nextcloud DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci;

> GRANT ALL PRIVILEGES ON nextcloud.* TO nextcloud@localhost IDENTIFIED BY ‘nextcloud’;

> \q

* данными командами мы создали базу данных nextcloud, затем с таким же названием мы создали пользователя и задали ему пароль nextcloud.

Основы SELinux

SELinux представляет собой систему маркировки, каждый процесс имеет метку. Каждый файл, каталог или даже пользователь в системе имеет метку. Даже портам и устройствам и именам хостов в системе присвоены метки. SELinux определяет правила доступа процесса к объектам с определенными метками. Это и называется политикой. За соблюдением правил следит ядро. Иногда это еще называется обязательный контроль доступа (Mandatory Access Control, MAC)

Владелец файла не имеет полной свободы действий над атрибутами безопасности. Стандартные атрибуты контроля доступа, такие как группа и владелец ничего не значат для SELinux. Полностью все управляется метками. Значения атрибутов могут быть установлены и без прав root, но на это нужно иметь специальные полномочия SELinux.

Теперь поговорим немного о политиках. Мы определяем метку для процессов определенного типа, а также на объекты файловой системы тоже определенного типа. Вот представьте, себе систему, в которой объекты (процессы) это кошки и собаки. Это типы процессов. И у нас есть объекты, к которым они хотят иметь доступ — еда. Но еда у них разная еда_котов и еда_собак. Нужно чтобы объекты имели доступ только к своей еде.

У собаки есть разрешение есть свою пищу, а у кошки — свою. В политиках SELinux это будет выглядеть вот так:

Теперь ядро будет следить, чтобы соблюдались эти правила. В системе SELinux все по умолчанию запрещено, таким образом, если собака попытается съесть кошачий корм, ядро не позволит это сделать.

Допустим, процесс Apache имеет метку httpd_t, а файлы, к которым у Apache должен быть доступ мы назвали httpd_sys_content. Также у нас есть данные кредитных карт, которые хранятся в базе данных mysql. Если хакер взломает процесс Apache и у него будет root доступ, то он все равно не сможет получить доступ к файлам от mysql.

SELinux может вызвать у системных администраторов большое количество проблем, многие её просто отключают, таким образом, решив проблему и уменьшив безопасность. Как уже говорилось выше, по умолчанию SELinux блокирует все и вся. Это подходит под описание строгой политики. Но чтобы облегчить системным администраторам работу, были разработаны другие стандартные политики. Во многих дистрибутивах используется целевая политика (targeted), она охватывает около 200 сетевых служб и процессов, все же остальные программы запускаются и работают свободно, к ним никакие модели SELinux не применяются.

SELinux может работать в трех режимах — отключен, система полностью отключена и не работает, режим ограничений  Enforcing — программа активирована и блокирует все не соответствующие политикам действия и третий режим Permissive — только фиксировать нарушения.

Политики SELinux бывают тоже нескольких типов. Политика targeted, которую мы рассматривали выше относится к типу Type Enforcment (TE) политик, в которых управление доступом к файлам осуществляется на основе ролей. Сюда же относится политика strict. Есть ещё политики Multi-Level Security (MLS), в которых добавлены дополнительные категории, они сложные и ненужны рядовому пользователю, поэтому начинающим можно пока забыть об их существовании. Надо понять, что подсистема SELinux разработана военными для военных, поэтому обычным пользователям все её возможности вряд-ли понадобятся. В этой статье мы будем обсуждать именно политику targeted.

Теория в общих чертах рассмотрена. А теперь перейдем к практической части.

Краткое описание

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

В SELinux права доступа определяются самой системой при помощи специально определенных политик. Политики работают на уровне системных вызовов и применяются самим ядром (но можно реализовать и на уровне приложения). SELinux действует после классической модели безопасности Linux. Иными словами, через SELinux нельзя разрешить то, что запрещено через права доступа пользователей или групп. Политики описываются при помощи специального гибкого языка описания правил доступа. В большинстве случаев правила SELinux «прозрачны» для приложений, и не требуется никакой их модификации. В состав некоторых дистрибутивов входят готовые политики, в которых права могут определяться на основе совпадения типов процесса (субъекта) и файла (объекта) — это основной механизм SELinux. Две других формы контроля доступа — доступ на основе ролей и на основе многоуровневой системы безопасности. Например, «», «секретно», «совершенно секретно», «».

Самый простой для работы и с точки зрения поддержки тип политики — так называемая «целевая» политика, разработанная в рамках проекта Fedora. В рамках политики описано более 200 процессов, которые могут выполняться в операционной системе. Все, что не описано «целевой» политикой, выполняется в домене (с типом) . Процессы, работающие в этом домене, не защищаются SELinux. Таким образом, все сторонние пользовательские приложения будут без всяких проблем работать в системе с «целевой» политикой в рамках классических разрешений избирательной системы контроля доступа.

Кроме «целевой» политики, в состав некоторых дистрибутивов входит политика с многоуровневой моделью безопасности (с поддержкой модели Белла — Лападулы).

Третий вариант политики — «строгий». Тут действует принцип «что не разрешено, то запрещено» (принцип наименьших прав). Политика основывается на Reference Policy от компании Tresys.

SELinux был разработан Агентством национальной безопасности США, и затем его исходные коды были представлены для скачивания.

SELinux включён в состав ядра Linux (начиная с версии 2.6).

Также для функционирования SELinux требуются модифицированные версии некоторых утилит (ps, ls и других), которые обеспечивают поддержку новых функций ядра, и поддержка со стороны файловой системы.

Мониторинг текущих контекстных меток

Zls -Z-Zps Zauxnetstat -Ztulpen

Каждая контекстная метка всегда состоит из трех разных частей:

 User: user может быть распознан как _u в метке контекста; для большинства каталогов, установлено значение system_u.
 Role: role может быть распознана как _r в метке контекста. Большинство объектов помечены ролью object_r. В расширенном управлении SELinux конкретным пользователям SELinux могут быть назначены разрешения для определенных ролей SELinux.
 Type: контекст type может быть распознан как _t в метке контекста. Вы можете видеть, что к каталогам в  применяется широкий спектр типов контекста.

Заключение

Проект SELinux выбрался из пелёнок и уверенно движется в направлении
универсального средства обеспечения безопасности в Linux-системах. Вместе
с другими известными открытыми проектами, SELinux ведёт Linux к получению
высоких уровней безопасности по международным стандартам Common Criteria.
Сейчас уже можно сказать, что уровень безопасности Linux-систем, особенно
в вопросах организации мандатного доступа, достиг возможностей серьёзных
коммерческих систем. Однако, основанные на Linux решения превосходят
коммерческие аналоги не только низкой ценой, но и принципами открытой
разработки и активного участия сообщества.

Добавить комментарий

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

Adblock
detector