Network access protection linux

Про NAP, MAB и динамические VLAN-ы

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

Некоторые вещи описаны вскользь, т.к. общеизвестны либо достаточно подробно описаны во многих документах.

Технология номер один — NAP (Network Access Protection) от Microsoft — предоставление доступа к сети на основании состояния «здоровья» компьютеров. Другими словами — определяются некоторые политики в которых сказано, что для получения доступа к сети компьютер должен удовлетворять некоторым требованиям — например необходимо наличие антивируса, наличие антивируса с обновленными антивирусными базами, наличие работающего фаервола или службы автоматических обновлений и проч. Если компьютер удовлетворяет требуемым условиям, то доступ к сети предоставляется. Если не удовлетворяет, то доступ не предоставляется, либо предоставляется но ограниченный.

Технологию NAP можно применять в различных сценариях — с DHCP, IPSec’ом, RD-Gate’ом. В нашей небольшой организации NAP применяется совместно с протоколом 802.1X для проверки и предоставления\не предоставления доступа к сети устройствам подключенным к портам коммутаторов или по Wi-Fi. Т.е. как только компьютер подключается к сетевой розетке происходит аутентификация и проверка его соответствия заданным политикам — на основании результатов данной проверки коммутатору от RADIUS-сервера приходит мессейдж о том пускаем клиента в сеть или не пускаем. Если пускаем, то куда (VLAN).
Если компьютер не удовлетворяет заданным требованиям, то его можно переместить в карантинный VLAN, в котором данному компьютеру будет доступен некий сервер — сервер восстановления. С данного сервера можно скачать и установить например антивирус и попытаться повторно получить доступ к нужной сети.
Данный алгоритм работы предполагает, что все клиенты у нас получают адреса по DHCP — и это очень важный момент.

Технология номер два — MAB (MAC Authentication Bypass) от Cisco — аутентификация устройств подключенных к сети по MAC-адресам. Т.е. при подключении устройства к порту правильно-настроенного коммутатора (правильно-настроенный коммутатор в сеть кого попало без предварительной проверки не пропускает) происходит аутентификация подключенного девайса. Правильно-настроенный коммутатор пересылает соответствующий запрос RADIUS-серверу используя MAC-адрес девайса в качестве логина и пароля. Далее коммутатор уже ориентируется на ответ RADIUS-сервера — либо MAB-Success либо банан.

А теперь о том, как мы все это используем.

Как не трудно подметить, технология NAP отлично прилагается к девайсам типа компьютер, т.к. именно здесь реализоваться ее, технологии, потенциал (проверка на установленный антивирус, фаер, обновления. ) и не важно под какой ОС работает компьютер — есть, правда платные, реализации под Linux и вроде даже как под Mac. Для Windows многое бесплатно из коробки (коробка правда стоит денег).

С другой стороны MAB отлично прилагается к девайсам не особо сведущим о таких высоких материях как 802.1X или тем более NAP — т.е. принтера (хотя многие принтера и могут работать по 802.1X), сетевые сканеры, видео-регистраторы, холодильники…

Зная какие устройства используются в сети была разработана соответствующая хитрая схема адресации внутри этой самой сети с определением соответствующих VLAN-ов. Т.е. принтерам была выделена отдельная подсеть и назначен VLAN скажем 5. Компьютерам пользователей своя подсеть и VLAN скажем 6. Количество VLAN-ов и подсетей зависит от того, как именно требуется разграничивать доступ и вообще стоит ли это делать.
VLAN-ы, и это немаловажно, назначаются динамически — т.е. в какую бы розетку пользователь не воткнулся он получит доступ именно к своей сети (если конечно у него есть соответствующие “разрешения” и он удовлетворяет заданным политикам). Тоже самое и с другими девайсами. Случайны прохожий всюду получит банан.

Далее были развернуты RADIUS-сервера и нацелены на Active Directory. В свою очередь в AD были созданы спец. группы в которые добавляются учетные записи компьютеров (в зависимости от принадлежности к отделу\департаменту\… или требуемому уровню доступа).
Также в AD заводятся учетные записи пользователей соответствующие устройствам не понимающим NAP и 802.1X, которые будут проходить по MAB-у. Во время тестирования и настройки единственное что удалось найти в интернете про авторизацию по MAC-адресу (в частности на сайте Майкрософт) — MAC Address Authorization — статья, следуя которой MAB НЕ настроить. А настроить его можно так:

• в настройках NPS добавить к существующей политике протокол аутентификации PAP;
• прочитать указанную выше статью технета, и убедиться что у вас в реестре НЕТ данных ключей (в статье их рекомендуют создать);
• создать в AD учетки пользователей с именами и паролями соответствующими MAC-адресу устройства (маленькими буквами без разделителей);

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

Далее на RADIUS-серверах заводятся RADIUS-клиенты, т.е. коммутаторы от которых будут приходить запросы на аутентификацию и авторизацию.

Во времена, когда NAP только появился мы начали его разворачивать на Windows 2008 Standard и очень быстро уперлись, в нашей небольшой организации, в ограничение данной версии — стандартная версия с ролью NPS (Network Policy Server — он же в нашем случае RADIUS) поддерживает только 50 RADIUS-клиентов. В мануалах об этом конечно же написано, но как-то подзабиылось.

Помимо RADIUS-клиентов на серверах создаются соответствующие правила как для работы NAP-а, так и MAB-а. Правила примерно следующие — если запрос пришел из подсети xxx.xxx.xxx.xxx, и клиент входит в группу в AD YYY, да еще и удовлетворяет всем предъявляемым требованиям определенной политики (например имеется рабочий антивирус с актуальными базами и включенным фаерволом для всех сетевых подключений), то предоставляется полный доступ к сети — VLAN ZZZ.
Для MAB-а политика такая же, только без проверки состояния здоровья и проверяется уже членство в определенной группе пользователя, а не компьютера.

Как уже было сказано выше, для MAB-а используется протокол аутентификации PAP, для NAP-а, соответственно, PEAP. На PEAP-е стоит заострить внимание иначе в один прекрасный день это сделает сам PEAP. Дело в том, что PEAP завязан на сертификат сервера — в нашем случае это сертификат RAS IAS сервера. У сертификатов есть отличная способность — срок их действия однажды истекает. Поэтому неплохо позаботится заранее о политике autoenroll-а NPS-серверам соответствующих сертификатов, т.к. иначе десятки, сотни или быть может тысячи пользователей рискуют остаться без доступа к сети (в зависимости от размеров организации и степени проникновения NAP-а).

Далее идет настройка сетевого оборудования. Важно, чтобы коммутаторы поддерживали протокол 802.1X иначе фокус не получится. В нашей небольшой организации повсюду используются девайсы производства Cisco, но даже с ними были проблемы — необходимая поддержка появилась в более поздних версиях IOS-а.

Все что необходимо сделать на коммутаторах это:
— указать RADIUS-сервера и shared key;
— настроить необходимые порты.

Пример:
aaa authentication dot1x default group radius
dot1x system-auth-control
!
interface GigabithtEthernetX/X/X
switchport mode access
authentication order mab dot1x
authentication port-control auto
mab
dot1x guest-vlan XXX
spanning-tree portfast
!
radius-server host XXX.XXX.XXX.XXX auth-port 1812 acct-port 1813 key XXX

Собственно на этом настройка на сетевом оборудовании заканчивается.

Однако для того чтобы все это заработало необходимо, помимо всего прочего, выполнить некоторые настройки и на клиентских компьютерах. А именно — выставить в autostart службы Network Access Protection и Wired Autoconfig — по дефолту они в состоянии Manual.

Замечена особенность — при подключении компьютеров к сети через IP-телефоны Cisco совершенно разных моделей периодически возникает ситуация, когда телефон блокирует прохождение через себя EAP-пакетов. На некоторых телефонах это лечится включением в настройках параметра SPAN to PC. На многих телефонах такой настроки нет. Поэтому кому-то приходится подключаться мимо телефонов в сеть, либо перезагружать телефон. Есть ли похожие ништяки у других вендоров не известно — у нас используется только Cisco.

В результате мы получаем неплохую защиту нашей сети уже на этапе попытки подключения к ней. Уходим от таких вещей как port-security или за-shutdown-енные порты. В качестве бонуса получая динамически-назначаемые VLAN-ы.

В обчем и целом можно сказать, что технологии неплохие и вполне рабочие.

Источник

Системы защиты 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, всё работает.

Источник