Просмотр исходного текста страницы LXF158:Рубрика сисадмина: Знать свои слабости

[[Категория:Постоянные рубрики]]  


[[Файл:LXF00.tut1.chris2_fmt.png |left |100px |thumb|Д-р Крис Браун. 
Доктор обучает, пишет и консультирует по Linux. Ученая степень по физике элементарных частиц ему в этом совсем не помогает.]]  
<span style="color:black"><span style="font-size: 400%">  По рецептам доктора Брауна </span></span>

==Эзотерическое системное администрирование из причудливых заворотов кишок серверной==

{{Врезка|left|Заголовок=Назвался груздем |Ширина=30%|Содержание= 

Моя жена ведет кружок по пошиву лоскутных покрывал. Поотиравшись около их сборищ, я научился отличать узор «плетенка» от узора «лестничка», узнал, что дешевый ватин мохрится, и понял, как вырезать фестоны для «широких квадратов». Нет, я не выдумывал эти термины.

Свой жаргон есть у всех профессий. Но я бы сказал, что в мире открытого ПО его многовато. Где еще вы услышите, что обратный слэш экранирует звездочку, или получите советы погрепить в логах, отправить демону сигнал HUP, su’кнуть в root, пропатчить ядро или загрузить Grub? Где вы еще сможете запереть руткит в песочнице или уловить вредоносное ПО на «медовую приманку» [honeypot, ресурс-приманка, вызывает атаку на себя для изучения стратегии злоумышленника и определения защиты, – прим. пер.]? Где еще вы узнаете, что парень, с которым вы только что взяли по пиву, все еще работает в Lucid с «предками пространства ARM»? Эти термины я тоже не выдумал.

…надевай шляпу

Все это (в чем-то) подводит меня к недавно попавшейся мне книге «Gray Hat Hacking [Учебник серого хакера]», примечательной потрясающим набором охваченных тем.

Вы научитесь вводить в заблуждение охранные программы и создавать «медовую приманку». А зная Ассемблер, вы сможете подробно разобрать создание эксплойта и проведение анализа на уязвимости. Этически такие книги балансируют на грани между обучением «черных шляп» (плохих парней) и «белых шляп» (хороших парней).

В первых главах внимание уделяется вопросам этики, с основной идеей «нельзя должным образом защитить себя от угроз, которых не понимаешь». Эта книга не для слабаков (во многих аспектах), но если в названии вашей должности есть слово «безопасность», ее стоит прочесть.

chris.linuxformat@gmail.com
}}
=Знать свои слабости=

''Чтобы защитить свои компьютеры от нападения, нужно знать свои уязвимости. Вам поможет OpenVAS.''

Можно ли быть уверенным в том, что система защищена? Ну, на 100 % нельзя никогда. Но можно существенно повысить свою уверенность, запустив сканер уязвимостей, и во многих организациях это делается на регулярной основе.

OpenVAS – одна из таких программ. Это ответвление Nessus, популярного сканера, который в 2005 году превратился из открытого в коммерческий. К моменту чтения этой статьи должна выйти OpenVAS 5. OpenVAS запускает на главном компьютере сканирующий демон, который выполняет серию проверок на уязвимость для заданного набора объектов. Эти проверки называются проверками сетевой уязвимости (NVT – network vulnerability tests) и пишутся на простом скриптовом языке (Nessus Attack Scripting Language – язык описания атак Nessus).

==Тысячное войско==

Сейчас таких тестов чуть менее 25 000, и каждый день добавляются новые в ответ на новую информацию об угрозах безопасности, поступающую от производителей ПО и из отчетов исследователей. Около 16 000 из этих тестов основаны на информации от производителей ПО, обычно в такой форме: «О, у вас версия X приложения Y. Значит, у вас есть уязвимость Z». Другие тесты реально взаимодействуют с системой, определяя уязвимости. Качество работы OpenVAS, очевидно, зависит от качества тестов и своевременности их создания и распространения по мере обнаружения новых угроз. OpenVAS обеспечивает бесплатный приток тестов; есть также и коммерческий, от немецкой компании Greenbone, разработчика OpenVAS. Чтобы по-быстрому это попробовать, скачайте виртуальный экземпляр OpenVAS4 с сайта openvas.org; он совместим с VirtualBox и VMWare (сам я пробовал только последнее) и предоставляет сервер OpenVAS – с ним можно работать через утилиты командной строки или с помощью браузера через порт 9392. Надо сказать, что хотя его легко загрузить и установить, кривая его изучения довольно крута. Для практического использования установите сами пакеты OpenVAS. Возможно, они есть в репозиториях вашего дистрибутива.

Наконец, заострим, что запуск сканера уязвимостей сам по себе волшебным образом не повысит вам безопасность. Кто-то должен его отчеты читать и принимать меры. И во многих случаях достаточно просто обновить уязвимое приложение до более поздней версии.
{{Врезка|right|Заголовок=Взгляд изнутри |Ширина=30%|Содержание= Существует много других утилит сканирования. Bastille – утилита сканирования и укрепления системы, которая взаправду усилит безопасность системы и предложит краткий курс по безопасности в качестве бонуса. Проект некоторое время дремал, но, кажется, возвращается к жизни (www.bastille-unix.org). В отличие от OpenVAS, Bastille проверяет систему «изнутри», т. е. вы запускаете его на сканируемом компьютере.}} 
==Linux упрочняет защиту==

У SELinux репутация невероятно сложной системы, но он слишком важен, чтобы его игнорировать. Рассмотрим этот важный рубеж обороны.

Должен признаться, что при упоминании SELinux я веду себя как страус – прячу голову в песок и надеюсь, что он исчезнет. Но RedHat принимает его всерьез, и системным админстраторам приходится иметь с ним дело все чаще. И я решил, что лучше рассказать об его основах, хотя бы немного.

Прежде всего, зачем он нужен? В двух словах – его назначение в том, чтобы ограничить ущерб системы из-за атаки, воспользовавшейся уязвимостью в программе. Чтобы понять, как это работает, начнем с традиционной модели прав доступа к файлам в Linux, под которой я имею в виду известные разрешения rwx. В этой модели авторизация происходит исключительно по UID и GID процесса, выполняющего запрос. Если процесс запускается от имени пользователя chris, я вижу одни права доступа, если от имени root – другие, и т. д. Например, пусть я пользуюсь Firefox. Разумеется, браузеру нужен доступ к некоторым каталогам файловой системы – чтобы кэшировать cookie, записывать историю и т. д., но все мои файлы ему ни к чему. Однако если открыть в нем активное вредоносное содержимое, умеющее использовать уязвимость в браузере, злоумышленник потенциально получит доступ к тем же файлам, что и я (как пользователь chris).

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

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

Здесь традиционная модель безопасности в Linux становится бессильной, и управление на себя берет SELinux. Важно понимать, что решения об авторизации, принимаемые SELinux, дополняют, а не заменяют традиционную модель. Если права rwx не разрешают доступа – точка. Но если они разрешают, политики SELinux дают системе дополнительную возможность запретить его.
{{Врезка|left|Заголовок= Уязвимости дня|Ширина=30%|Содержание= Уязвимость программы – недостаток программы, позволяющий злоумышленнику заставить программу сделать нечто для нее нештатное. В идеальном мире у программ не было бы уязвимостей (вообще-то в истинно идеальном мире не было бы и злоумышленников, но это другая история).

В реальности уязвимости иногда обнаруживаются. И тогда разработчики программ должны срочно взяться за проблему и выпустить заплатку или обновление, а системные администраторы (это вы!) должны установить его.

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

Они-то и вызывают у системных администраторов приступы паранойи, и служат движителем разработки систем управления доступом вроде SELinux.
}}

==Невообразимая сложность==
{| class="wikitable" style="float:right; margin-left:0.8em; width:50%"
|-
|  ПОЛЬЗОВАТЕЛЬ [USER]
| Это пользователь SELinux, 
|-
|  РОЛЬ [ROLE]
| используется для управления доступом на основе ролей (role-based access control – RBAC). Пользователи авторизуются для получения определенных ролей, а роли определяют, к каким ресурсам у пользователя есть доступ. Роли используются в управлении процессами, но файлы, которые по сути пассивны, на самом деле не пользуются ролями, и для них используется «пустая роль» object_r.
|-
| ТИП [TYPE] 
| Это главные атрибуты безопасности, которыми SELinux руководствуется при принятии решения о доступе. При применении к процессам типы также называются доменами и по сути определяют именованную «песочницу», в которой выполняется процесс.
|-
|УРОВЕНЬ [LEVEL]
|С помощью этого атрибута реализуется многоуровневая система доступа – в ее основе лежит идея о том, что документы могут быть «публичными», «конфиденциальными», «совершенно секретными» и т. д.
|}
Детали устройства SELinux, мягко говоря, непросты. Но давайте окунемся в них и узнаем, сможем ли мы хотя бы почувствовать их аромат. Если начинать с самого начала, то у каждого файла и каждого процесса в системе SELinux есть контекст безопасности, в который входят четыре составляющих:



Привязка контекстов безопасности к файлам называется «пометкой» файловой системы.

Контекст безопасности файла можно просмотреть, скомандовав ls -Z:

 # ls -Z /usr/bin/ssh

 -rwxr-xr-x. root root system_u:object_r:ssh_exec_t:s0 /usr/bin/ssh

Здесь мы видим, что у файла есть собственный тип ssh_exec_t.

Обычный файл пользователя в домашнем каталоге может выглядеть так:

$ ls -lZ sample

-rw-r--r--. chris chris unconfined_u:object_r:user_home_t:s0 sample

Обратите внимание, что в качестве владельца SELinux отображается unconfined_u, как мы упоминали ранее.

Контекст безопасности процесса можно просмотреть командой ps -Z:

 # ps -eZ | grep sshd

 system_u:system_r:sshd_t:s0-s0:c0.c1023 1508 ? 00:00:00 sshd

Здесь мы опять же видим, что у демона ssh есть собственный домен (sandbox, песочница) по имени sshd_t.

Вся эта новая информация, связываемая с файлами и процессами, требует изменения ряда стандартных утилит, чтобы они «знали» о SELinux. Например, ls, ps и id расширяются с целью отображения контекста безопасности файлов, процессов и пользователей соответственно. Утилиты управления файлами, типа cp и mv, изменяются так, чтобы сохранять контекст безопасности для создаваемых ими файлов. Даже у tar появляется возможность сохранять контексты безопасности файлов в архив (и восстанавливать их). Кроме того, есть несколько утилит SELinux для управления контекстами безопасности – к ним относятся restorecon, secon, chcon, findcon и setfiles. Быстрый поиск с помощью apropos нашел в общей сложности не менее 41 команды, имеющей отношение к SELinux.

==Не наша это политика…==

Все это вместе связывает SELinux Policy [политика SELinux], которая по сути представляет собой набор правил вида «процесс, выполняющийся в домене X, может получить доступ к файлам типа Y». Если вам нравится метафора с песочницей, то политики определяют границы песочницы. Вся система чрезвычайно детализирована. Чтобы дать вам представление о ее масштабе, скажу, что в пакете RHEL6 selinux-policy («образец политики») почти 400 файлов политик, а число строк в них превышает 350 000. Политика для одного только Apache состоит из 1400 строк. Впрочем, знайте, что перед загрузкой в ядро эти политики компилируются в двоичную форму.

Планируя эту статью, я наивно полагал, что сумею объяснить, как пишется политика. Но по мере моего продвижения стало ясно, что если наш главред не отдаст мне львиную долю этого номера, ничего не получится. Даже 82-страничное руководство пользователя по SELinux в RedHat и близко не подходит к написанию политик. Там даже не приведено примера. Существуют программы, которые помогают в анализе и разработке политик (например, apol и SLIDE, обе от Tresys), но это уже выходит за рамки данной статьи. Большинство администраторов будут расценивать политики SELinux так же, как исходные коды ядра – теоретически их при необходимости можно изменить, но на практике вы вряд ли будете этим заниматься. (Вы знаете разницу между теорией и практикой? Так вот, в теории нет разницы, а на практике она есть...)

Red Hat и Fedora (по-моему, единственные дистрибутивы, создающие что-то реально полезное с SELinux), проводят так называемую «целевую» политику. То есть, они в основном ограничивают сервисы, которые слушают сеть, а также несколько программ, которые изменяют setuid на root, таких как /usr/bin/passwd. Они не ограничивают деятельность, скажем, вошедшего в систему пользователя. Так, например, контекст безопасности обычного пользователя выглядит так:

$ id -Z

unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

Прежде чем паниковать при мысли о пользователях с «неограниченными [unconfined]» правами, вспомните, что традиционную модель прав доступа в Linux никто не отменял, просто SELinux пока не настроен на дальнейшее ограничение доступа.

==Настройка==

SELinux позволяет в некоторой степени изменить настройки без необходимости переписывать политики. На самом общем уровне можно изменять значение параметра SELINUX в /etc/selinux/config на Disabled [Отключен], Permissive [Толерантный] или Enforcing [Усиленный]. Назначение первого и третьего режимов понятно по названиям, а второй, пожалуй, требует пояснения. В этом режиме доступ, запрещаемый политикой, разрешается, но соответствующие действия записываются в файл журнала. С помощью этого режима удобно убедиться, что ваши настройки не выведут систему из строя после переключения в режим Усиленный. Есть даже утилита audit2allow, которая сгенерирует правила политики SELinux по лог-файлам операций, которым было отказано в доступе.

Определить, в каком режиме вы находитесь сейчас, можно командой sestatus:

 # sestatus

 SELinux status: enabled

 SELinuxfs mount: /selinux

 Current mode: enforcing

 Mode from config file: enforcing

 Policy version: 24

 Policy from config file: targeted

Более тонкий контроль обеспечивается логическими правилами SELinux. С их помощью администратор может разрешить или запретить определенный доступ локально без необходимости перезагрузки или перекомпиляции политики SELinux. Примеры логических правил таковы: «Разрешить https доступ к файловым системам nfs», «Разрешить системе запускаться с NIS», «Разрешить samba открывать домашние каталоги пользователей для общего доступа». Команда

getsebool -a

выведет все логические правила. В моей собственной тестовой системе RHEL6 их 168.

==Бурный инцидент==

Если вы играете не по правилам, SELinux запросто подпрыгнет и укусит вас. В качестве такого примера расскажу историю, имевшую место на одном из недавних занятий. Курс содержал упражнение для студентов – восстановить утерянный пароль пользователя root. 
[[Файл:LXF158.sysadmin.securit_opt.png | |thumb|400px|]]
[[Файл:LXF158.sysadmin.apolsc_opt.jpeg |left |600px |thumb| Apol, одна из графических утилит от Tresys, помогает анализировать политики SELinux.]]
Чтобы «потерять» пароль, студенты запускали скрипт, который (тайно) модифицировал файл /etc/shadow, примерно такой:

sed s/foo/bar /etc/shadow > /tmp/newshadow

mv /tmp/newshadow /etc/shadow

chmod 400 /etc/shadow

Скрипт создавал новый, измененный файл с неработающим паролем root и переименовал его обратно в /etc/shadow. И студентам пришлось сделать спасательную перезагрузку системы и сбросить пароль root. В системе без SELinux у них бы все получилось.

Что же произошло? Им вообще не удалось войти в систему – ни от имени root, ни от имени любого другого пользователя. Проблема в том, что у файла shadow особый контекст безопасности SELinux. А у вновь созданной копии файла был другой контекст безопасности. Как следствие, после перезагрузки системы даже программа login (которая запускается от имени root) не смогла прочитать файл shadow. Результат? Входа нет! Хотя это прекрасно иллюстрирует мощь SELinux, именно в такие ситуации преподаватель меньше всего жаждет попасть на уроках; впрочем, у нас не было выбора.

==Неусиленный режим==

Нам удалось восстановить систему, прервав загрузку и добавив enforcing=0 к списку параметров, которые Grub передает ядру. Тогда ядро запускается с неусиленным режимом SELinux, в котором мы по крайней мере смогли войти в систему. Чтобы полностью восстановить систему, мы выполнили команду:

 # restorecon /etc/shadow

которая вернула прежний контекст безопасности файла.

В чем мораль сей басни? Конечно, не стоит менять файл shadow так, как это сделали мы. Нужно пользоваться командой passwd, которая сохранит верный контекст безопасности SELinux. Но мы сделали такое, от чего не знакомый с SELinux администратор не ждал бы ничего плохого, вот и огребли.

Проанализируем произошедшее подробнее. У исходного файла /etc/shadow была такая метка:

 # ls -lZ /etc/shadow

----------. root root system_u:object_r:shadow_t:s0 /etc/shadow

После запуска скрипта метка стала такой:

 # ls -lZ /etc/shadow

 ----------. root root unconfined_u:object_r:user_tmp_t:s0 /etc/shadow

Изменились и владелец файла в SELinux, и «тип» метки. После возвращения в нормальное состояние болтливая запись в /var/log/audit/audit.log сообщает нам, что произошло:

type=AVC msg=audit(1330372308.768:52621): avc: denied {

read } for pid=28670 comm=”unix_chkpwd”

name=”shadow” dev=dm-0 ino=815961

scontext=system_u:system_r:chkpwd_t:s0-s0:c0.c1023 tconte

xt=unconfined_u:object_r:user_tmp_t:s0 tclass=file

Взглянув на нее внимательно, вы увидите, что процессу в домене chkpwd_t был запрещен доступ к файлу типа user_tmp_t, а это тип нашего (испорченного) файла shadow. Тип type=AVC, который вы здесь видите – ссылка на кэш векторов доступа (Access Vector Cache), хранилище недавно принятых SELinux решений о разрешении или запрещении доступа.

Кстати, с помощью команды aureport можно извлечь сообщения SELinux из лог-файла в более удобном для восприятия формате.

==И в заключение…==

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

Если у вас есть опыт работы с SELinux (удачный или не очень), черкните мне пару строк на chris.linuxformat@gmail.com. Было бы особенно интересно услышать тех, кому SELinux помог отразить настоящую атаку на их систему. Ведь именно ради этого мы и городим огород. |
 
 

==К истокам==

SELinux изначально разрабатывался в Агентстве национальной безопасности США (в общих чертах – аналог Центра правительственной связи Великобритании, см. http://www.nsa.gov/research/selinux). Большинство других утилит также были разработаны компанией Tresys (см. oss.tresys.com), ей принадлежит большой набор утилит (как консольных, так и графических) для анализа и разработки политик.

===Где узнать больше===

Книга Билла Маккарти [Bill McCarty] по SELinux (опубликованная в издательстве «О’Рэйли») – в некотором смысле наиболее полная работа, хотя она и вышла в 2004 г. и ее возраст неизбежно сказывается. Руководство пользователя по SELinux в RedHat (http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux) – более практичное и современное. Также масса информации есть на сайте selinuxproject.org.