Linux как средство защиты информации

Средства защиты информации в ОС Linux

Защита информации в конкретной операционной системе неразрывно связана с задачами, для решения которых применяется данная ОС. Unix-подобные операционные системы, и в частности Linux, изначально использовались в качестве сетевых ОС на серверах локальных вычислительных сетей. И сейчас по статистике проекта Netcraft примерно 89% серверов в сети Интернет работают под управлением таких операционных систем. Среди последних немалую часть составляют различные модификации Linux.

Из-за специфичности областей применения архитектура ОС Linux во многом отлична от архитектуры, например, ОС Windows, а сама система менее знакома массовому пользователю. Ожесточенные споры между поклонниками этих операционных систем вызывает вопрос, что лучше: Linux или Windows? Невозможно также однозначно ответить, какая из систем устойчивее и безопаснее, поскольку области их применения различны и задуманы они были для решения совершенно разных задач.

Что такое Linux?

Linux представляет собой полностью многозадачную многопользовательскую операционную систему. Основной составляющей частью ее является ядро. Именно ядро отличает Linux от других Unix-подобных операционных систем. Несмотря на то что существует множество дистрибутивов иногда с абсолютно различными принципами настройки и процессами начальной загрузки, все они имеют общее ядро. Любой желающий, приложив некоторые усилия, может собрать собственный дистрибутив на основе одного из стандартных ядер. Собственно, ядро системы — это и есть то, что принято называть Linux. Разработчики дистрибутивов нередко вносят в стандартное, также называемое каноническим, ядро какие-то свои изменения, но они по большей части касаются работы специфичного для этих дистрибутивов программного обеспечения. Ядро имеет, как правило, модульную структуру, модули ядра можно задействовать (подгружать) по мере необходимости, чаще всего модулями оформлены драйверы периферийных устройств и файловых систем.

Структура ядра ОС Linux

Кроме ядра в системе существуют постоянно выполняющиеся в памяти процессы, называемые демонами. Демоны — аналоги резидентов в DOS и служб в Windows. Стартуют в качестве демонов те программы, для работы которых не требуется вмешательства пользователя; обычно это различные серверы. Например, сервер MySQL — mysqld, сервер Apache — httpd.

Неуловимый Джо

К сожалению, очень распространен ряд заблуждений, связанных с безопасностью Linux. Некоторые пользователи убеждены в том, что Linux абсолютно защищена сразу после установки и не требуются никакие дополнительные меры, направленные на увеличение ее безопасности. Как один из вариантов подобного заблуждения бытует мнение, что «вирусов под Linux не бывает». Отсутствие вирусов объясняют особенностями архитектуры системы, которая делает их существование невозможным. Данное мнение не совсем верно: вирусы и другие вредоносные программы под Linux встречаются, хотя и не в таком количестве, как под ОС семейства Windows. Особенностью вредоносных программ под Linux является то, что для начала своих деструктивных действий они требуют прямого вмешательства пользователя. Самопроизвольной активации вируса без участия пользователя (обычная ситуация в Windows, например, в случае вирусов MSBlast, NetSky. ) не происходит. Таким образом, малое количество вирусов объясняется слабой распространенностью Linux именно в качестве операционной системы для пользовательского компьютера. Подобная ситуация складывалась с ОС Windows NT 4.0 во времена ее появления. Вирусов под нее было очень мало, и написать серьезный вирус считалось невозможным из-за того, что ее архитектура была недостаточно изучена авторами вирусов да и система тогда еще не приобрела популярности. Аналогичное положение до сих пор сохраняется для системы NetWare, внутренняя архитектура которой мало знакома неспециалистам.

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

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

Человеческий фактор

Самый страшный враг пользователя — это он сам. В подтверждение данного высказывания можно привести простой пример. В Linux, как и в любой Unix-подобной системе, существует специальный пользователь root, называемый также суперпользователем. Root имеет практически неограниченные права и может выполнять в системе любые действия. Согласно идеологии Unix, пользователь root предназначен только для внесения изменений в критичные системные настройки и установки программ, которые требуют прав на запись в системные каталоги. К сожалению, достаточно часто root используется для выполнения повседневных операций, например посещения веб-страниц, чтения личной почты. И однажды пользователь, просматривающий веб-форум под учетной записью root, встречает там просьбу помочь отладить программу, состоящую всего из одной строки на языке Perl.

Программа написана в лучших традициях программирования на Perl и выглядит как набор вполне бессмысленных символов (скрипт был опубликован в форуме linux.org.ru, автор неизвестен).

cat «test. test. test. » | perl -e ‘$??s:;s:s;;$. s;;=]=>%-< Схема комплексной защиты сети

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

Система обнаружения вторжений

Кроме DDoS-атак на сервер могут предприниматься так называемые DoS-атаки. Для атак подобного типа не нужно участие множества компьютеров, в отличие от DDoS эти атаки проходят незаметно, и виден только их конечный результат — неработоспособность сервера, исчезновение данных, нежелательная сетевая активность. Для обнаружения попыток подобных вторжений извне в ОС Linux существует большое количество специализированного ПО. Эти программы объединены под общим названием IDS (Intrusion Detection System — системы обнаружения вторжений). Самой популярной IDS на сегодняшний день считается система Snort.

Snort использует специальный язык правил, которыми дается описание потенциально опасного сетевого трафика. Формат правил похож на формат пакетных межсетевых экранов под Linux. В правилах можно задать реакцию на подозрительное содержимое любой части IP-пакета. Snort обладает модульной архитектурой и может контролировать сетевую активность на любом уровне сетевого интерфейса, начиная с канального и заканчивая прикладным. При обнаружении трафика, подпадающего под заданные правила, snort может разорвать соединение с компьютером, от которого он исходит, заблокировать его IP-адрес и внести запись в журнал.

Защита почтового сервера

Работа в качестве mail-сервера — одно из самых распространенных применений серверов под управлением Linux. Проблема безопасности сообщений электронной почты появилась одновременно с введением достаточно небезопасных протоколов обмена mail-сообщениями, таких как POP3 и SMTP. Во времена их создания мало кто задумывался, что передача такой информации, как имя пользователя, пароль, да и содержания письма в открытом виде является не самой лучшей реализацией схемы обмена информацией. В обоих протоколах не было предусмотрено возможности точной идентификации отправителя и его обратного адреса. Отсюда основные проблемы электронной почты — анонимные спам-сообщения, рассылка вирусов и перехват почтового трафика.

Главным средством реализации почтового сервера на базе Linux является программный пакет Sendmail. Можно сказать, что на сегодняшний момент Sendmail — лучший инструмент для построения системы управления почтовой корреспонденцией. При помощи Sendmail можно организовать практически любую теоретически возможную схему управления почтой. Приятной особенностью его архитектуры является реализованный в нем интерфейс работы с внешними модулями — milter. Благодаря milter появляется возможность отправлять почтовые сообщения на обработку внешним программам, поддерживающим взаимодействие по этому интерфейсу. Такими программами могут быть различные антивирусные пакеты и фильтры содержимого сообщений. Из популярных программных решений, выполненных как модули Sendmail, можно упомянуть из антивирусов, например, антивирусный пакет DrWeb for Unix, а также открытую разработку — антивирус Clamav. Для борьбы с нежелательными сообщениями часто применяется пакет анализа содержимого Spamassassin. Для обеспечения закрытости почтовой переписки существует отечественное криптографическое решение, выполненное также в виде модуля milter к пакету Sendmail, — комплекс «Криптон-почта».

ОБ АВТОРЕ

Сергей Александрович Ермаков — руководитель группы тестирования программного обеспечения фирмы «АНКАД». С ним можно связаться по e-mail: develop@ancud.ru .

Статью «Средства защиты информации в ОС 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, всё работает.

Источник