Операционная система Linux

Размещено на http://www.allbest.ru/

Введение

Операционная система, сокр. ОС (англ. operating system, OS) -- комплекс управляющих и обрабатывающих программ, которые, с одной стороны, выступают как интерфейс междуустройствами вычислительной системы и прикладными программами, а с другой стороны -- предназначены для управления устройствами, управления вычислительными процессами, эффективного распределения вычислительных ресурсов между вычислительными процессами и организации надёжных вычислений. Это определение применимо к большинству современных операционных систем общего назначения.

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

Разработчикам программного обеспечения операционная система позволяет абстрагироваться от деталей реализации и функционирования устройств, предоставляя минимально необходимый набор функций (см.: интерфейс программирования приложений).

В большинстве вычислительных систем операционная система является основной, наиболее важной (а иногда и единственной) частью системного программного обеспечения. С 1990-х годов наиболее распространёнными операционными системами являются системы семейства Windows и системы класса UNIX (особенно Linux и Mac OS).

Мы живем в 21 веке, в веке информационных технологий, и конечнечно же каждый из нас с вами в той или иной степени связан с сетями общего пользования. Интернет в настоящее время играет не моловажную роль в жизни каждого человека. От общения в социальных сетях, до крупных сделок на уровне корпораций и государств. Он универсален. И конечно же самым главным для каждого человека, который давно включил интернет в свою жизнь, так как он очень прост в использовании и упрощает нам жизнь, является безопасность.

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



1. Критерии определения безопасности операционных систем

Критерии определения безопасности компьютерных систем (англ. Trusted Computer System Evaluation Criteria) -- стандарт Министерства обороны США, устанавливающий основные условия для оценки эффективности средств компьютерной безопасности, содержащихся в компьютерной системе. Критерии используются для определения, классификации и выбора компьютерных систем, предназначенных для обработки, хранения и поиска важной или секретной информации.

Критерии, часто упоминающиеся как Оранжевая книга, занимают центральное место среди публикаций «Радужной серии» Министерства обороны США. Изначально выпущенные Центром национальной компьютерной безопасности США в качестве орудия для Агентства национальной безопасности в 1983 году и потом обновлённые в 1985.

Аналогом Оранжевой книги является международный стандарт ISO/IEC 15408, опубликованный в 2005 году. Это более универсальный и совершенный стандарт, но вопреки распространенному заблуждению, он не заменял собой Оранжевую книгу в силу разной юрисдикции документов -- Оранжевая книга используется исключительно Министерством Обороны США, в то время как ISO/IEC 15408 ратифицировали множество стран, включая Россию.

linux iso операционный



2. Общие критерии оценки защищённости информационных технологий

Англ. Common Criteria for Information Technology Security Evaluation. Общеизвестным является более короткое название Общие критерии (Common Criteria, CC, или ОК). Международный стандарт (ISO/IEC 15408,ИСО/МЭК 15408-2002) по компьютерной безопасности. В отличие от стандарта FIPS 140 , Common Criteria не приводит списка требований по безопасности или списка особенностей, которые должен содержать продукт.

Вместо этого он описывает инфраструктуру (framework), в которой потребители компьютерной системы могут описать требования, разработчики могут заявить о свойствах безопасности продуктов, а эксперты по безопасности определить, удовлетворяет ли продукт заявлениям. Таким образом, Common Criteria позволяет обеспечить условия, в которых процесс описания, разработки и проверки продукта будет произведён с необходимой скрупулёзностью.

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

Чтобы структурировать пространство требований, в стандарте используется иерархия класс-семейство-компонент-элемент: классы определяют наиболее общую, «предметную» группировку требований, семейства в пределах класса различаются по строгости и другим нюансам требований, компонент -- минимальный набор требований, фигурирующий как целое, элемент -- неделимое требование.



2.1 Функциональные требования

Функциональные требования сгруппированы на основе выполняемой ими роли или обслуживаемой цели безопасности, всего 11 функциональных классов (в трёх группах), 66 семейств, 135 компонентов.

Первая группа определяет элементарные сервисы безопасности:

а)FAU -- аудит, безопасность (требования к сервису, протоколирование и аудит);

б)FIA -- идентификация и аутентификация;

в)FRU -- использование ресурсов (для обеспечения отказоустойчивости).

Вторая группа описывает производные сервисы, реализованные на базе элементарных:

а)FCO -- связь (безопасность коммуникаций отправитель-получатель);

б)FPR -- приватность;

в)FDP -- защита данных пользователя;

г)FPT -- защита функций безопасности объекта оценки.

3.Третья группа классов связана с инфраструктурой объекта оценки:

а)FCS -- криптографическая поддержка (обслуживает управление криптоключами и крипто-операциями);

б)FMT -- управление безопасностью;

в)FTA -- доступ к объекту оценки (управление сеансами работы пользователей);

г)FTP -- доверенный маршрут/канал;

2.2 Классы функциональных требований к элементарным сервисам безопасности

К элементарным сервисам безопасности относятся следующие классы FAU, FIA и FRU.

Класс FAU включает шесть семейств (FAU_GEN, FAU_SEL, FAU_STG, FAU_SAR, FAU_SAA и FAU_ARP), причём каждое семейство может содержать разное число компонентов.

Назначение компонент данного класса следующее.

FAU_GEN -- генерация данных аудита безопасности. Содержит два компонента FAU_GEN.1 (генерация данных аудита) и FAU_GEN.2 (ассоциация идентификатора пользователя).

2.3 Требования доверия

Требования гарантии безопасности (доверия) -- требования, предъявляемые к технологии и процессу разработки и эксплуатации объекта оценки. Разделены на 10 классов, 44 семейства, 93 компонента, которые охватывают различные этапы жизненного цикла.

Первая группа содержит классы требований, предшествующих разработке и оценке объекта:

а)APE -- оценка профиля защиты;

б)ASE -- оценка задания по безопасности.

Вторая группа связана с этапами жизненного цикла объекта аттестации:

а)ADV -- разработка, проектирование объекта;

б)ALC -- поддержка жизненного цикла;

в)ACM -- управление конфигурацией;

г)AGD -- руководство администратора и пользователя;

дATE -- тестирование;

е)AVA -- оценка уязвимостей;

ж)ADO -- требования к поставке и эксплуатации;

з)АMA -- поддержка доверия-требования, применяется после сертификации объекта на соответствие общим критериям.

2.4 История создания « Общих критериев»

Разработке «Общих критериев» предшествовала разработка документа «Критерии оценки безопасности информационных, технологий». (англ. Evaluation Criteria for IT Security, ECITS), начатая в 1990 году , и выполненная рабочей группой 3 подкомитета 27 первого совместного технического комитета (или JTC1/SC27/WG3) Международной организации по стандартизации (ISO).

Данный документ послужил основой для начала работы над документом Общие критерии оценки безопасности информационных технологий (англ. Common Criteria for IT Security Evaluation), начатой в 1993 году. В этой работе принимали участие правительственные организации шести стран (США, Канада, Германия, Великобритания, Франция, Нидерланды). В работе над проектом принимали участие следующие институты:

Национальный институт стандартов и технологии и Агентство национальной безопасности (США);

Учреждение безопасности коммуникаций (Канада);

Агентство информационной безопасности (Германия);

Органы исполнения программы безопасности и сертификации ИТ (Англия);

Центр обеспечения безопасности систем (Франция);

Агентство национальной безопасности коммуникаций (Нидерланды).

Стандарт был принят в 2005 году комитетом ISO и имеет статус международного стандарта, идентификационный номер ISO/IEC 15408. В профессиональных кругах за этим документом впоследствии закрепилось короткое название -- англ. Common Criteria, CC; рус. «Общие критерии», ОК.

Что это значит?

Итак, допустим некий продукт сертифицирован в соответствии со стандартом ISO/IEC 15408. О каком уровне защищённости это говорит?

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

Операционая система Microsoft Windows XP (исходная версия, без SP1) была сертифицирована на уровень Common Criteria EAL4+, после чего для неё было выпущено три пакета обновлений (service pack) и регулярно выпускаются новые критические обновления безопасности. Тем не менее, Windows XP в исходной версии по-прежнему обладает сертификатом EAL4+, никаких дополнительных сертификаций не проводилось. Это факт говорит о том, что условия сертификации (окружение и модель злоумышленника) были подобраны весьма консервативно, в результате чего ни одна из обнаруженных уязвимостей не применима к протестированной конфигурации. Разумеется, для реальных конфигураций многие из этих уязвимостей представляют опасность. Microsoft рекомендует пользователям устанавливать все критические обновления безопасности.



3. Безопасность ОС Linux в соответствии со стандартами ISO

Сравним ОС Linux на наличие трех групп фунцкиональных требований (стандарт ISO/IEC 15408.):

Первая группа определяет элементарные сервисы безопасности:

а)FAU -- аудит, безопасность (требования к сервису, протоколирование и аудит);

б)FIA -- авторизация пользователей;

в)FRU -- использование ресурсов (для обеспечения отказоустойчивости).

Вторая группа описывает производные сервисы, реализованные на базе элементарных:

а)FCO -- сетевая безопсность;

б)FPR -- приватность;

в)FDP -- защита данных пользователя;

г)FPT -- анализ уязвимостей (оценка безопасности ОС)

Третья группа классов связана с инфраструктурой объекта оценки:

а)FCS -- криптографическая поддержка (обслуживает управление криптоключами и крипто-операциями);

б)FMT -- управление безопасностью;

в)FTA -- доступ к объекту оценки (управление сеансами работы пользователей);

г)FTP -- доверенный маршрут/канал;

3.1 Первая группа функциональных требований

3.1.1 Аудит системных событий Linux (FUA)

Системный журнал.

Нормальной практикой большинства приложений для ОС Linux, в том числе и для ядра системы, является запись всех важных событий в жизни приложений в системный журнал. Системный журнал - это фактически аналог «черного ящика» или судового журнала. В Linux ведение журнала предоставлено отдельному системному сервису syslog, а в случае ядра - klog. Записи системного журнала имеют определенный формат, в котором указывается время события, имя процесса, приоритет события и строка, отражающая событие. На самом деле, системный журнал, как правило, состоит из нескольких файлов в каталоге /var/log. Имена файлов и тип событий в этих файлах можно настраивать. Чем же полезен системный журнал? В первую очередь, большинство непредвиденных ситуаций возникают вовсе не вдруг и не в пятницу вечером, большинство из них имеет вполне определенные предшествующие изменения в характере работы системы. Эти изменения можно иногда зафиксировать при помощи анализа системного журнала: скажем, проанализировать периодичность какоголибо события или адекватность его в контексте работы системы. Таким образом, можно выявить, например, подозрительную активность хакеров или неочевидные ошибки конфигурации. Для анализа подобных ситуаций применяются средства автоматизации, один из них logcheck. Так как создание универсального инструмента анализа системных журналов - задача бессмысленная, для анализа системного журнала чаще всего пользуются собственными средствами. Лучше, если этим средством окажется какая-нибудь программа, а не администратор системы.

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

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

В ОС Linux, начиная с версии ядра 2.6, существует возможность журналировать такие события, как доступ к файлам и выполнение системных вызовов. Процесс организации аудита системных событий ОС Linux состоит из следующих действий:

- Установка и настройка аудита (auditd).

- Настройка правил аудита, удовлетворяющих заданным условиям.

- Запуск аудита (auditd).

- Анализ полученных данных и создание отчетов аудита.

По умолчанию системный аудит отключен. Для его активации необходимо настроить запуск ядра с параметром audit=1. Если данный параметр присутствует, а демон auditd не запущен, то события журналируются в файл /var/log/messages.

Для того чтобы использовать аудит, в системе необходимо установить пакет audit. Демон auditd позволяет системному администратору настраивать процесс аудита, а именно:

- Задавать отдельный файл для журналирования событий.

- Определять ротацию журнального файла событий.

- Задавать оповещения в случае переполнения журнала событий.

- Определять уровень детализации событий.

- Настраивать правила аудита.

В процессе своей работы демон auditd использует конфигурационный файл /etc/audit/auditd.conf. На каждой строке данного файла указываются соответствующие директивы, значения которых указываются после знака «=».

log_file = /var/log/audit/audit.log

log_format = RAW

priority_boost = 3

flush = incremental

freq = 20

num_logs = 4

dispatcher = /sbin/audispd

disp_qos = lossy

max_log_fi1e = 5

max_log_file_action = rotate

space_left = 75

space_left_action = syslog

action_mail_acct = root

admin_space_left = 50

admin_space_left_action = suspend

disk_full_action = suspend

disk_error_action = suspend

Значения по умолчанию для конфигурационного файла /etc/audit/auditd.conf

В директиве log_file указывается файл, куда будут журналироваться события. По умолчанию, таки м файлом является файл /var/log/audit/audit.log. В директиве log_format указывается формат данных, которые необходимо журанлировать. В случае указания значения RAW в данной директиве, события записываются в файл в том виде, в котором они поступают из ядра. В директиве flush определяется частота журналирования событий. Если для данной директивы указано значение INCREMENTAL, то очистка журнала определяется на основе директивы freq, в которой указывается количество записей, которые принимает демон auditd, прежде чем записать их в журнал.

Если в файле auditd.conf указана директива max_log_file_action со значением ROTATE, то журнальные файлы будут ротироваться, достигнув размера, заданного в директиве max_log_file (в Мб). В директиве num_logs определяется количество журнальных файлов, которые должны быть сохранены, прежде чем будет выполнена ротация данных.

В директиве dispatcher задается программа, которая обрабатывает все события аудита. Она может использоваться для формирования отчетов или конвертации журнала в формат, понимаемый другими программами анализа журнальных файлов. Директива disp_qos определяет параметры взаимодействия данной программы с демоном auditd. Если в данной директиве указано значение lossy, то события, посланные данной программе, удаляются, если буфер обмена данными между демоном auditd и данной программой полностью заполнен (по умолчанию размер данного буфера составляет 128Кб). Запись событий по-прежнему осуществляется, если в директиве log_format не указано значение nolog.

В директивах space_left и space_left_action задается, соответственно, предел свободного дискового пространства раздела, на котором располагаются данные аудита, и действие, которое нужно выполнить в случае превышения указанного предела. Если указано значение SYSLOG, то в журнал сервиса syslog будет записано соответствующее предупреждение. В директивах disk_full_action и disk_error_action указываются, соответственно, действие выполняемое в случае заполнения дискового пространства на разделе, содержащем журнальные файлы аудита, и действие выполняемое в случае обнаружения ошибки записи данных в журнальный файл или его ротации. По умолчанию, для данных директив задано значение SUSPEND, при котором следующие события записываться в журнальный файл аудита не будут, а действия, выполняемые в настоящий момент над журнальным фалом, завершатся.

Для настройки правил аудита системных вызовов и слежения за файлами и каталогами используется утилита auditctl. Если сервис auditd настроен на автозапуск, то правила аудита системных вызовов и слежения за объектами файловой системы можно задать в файле /etc/audit/audit.rules. Каждое правило аудита должно задаваться в отдельной строке. Форма записей правил и средств имеет вид аргументов командной строки для команды auditctl. Демон auditd считывает правила сверху вниз и если будет обнаружено два конфликтующих правила, то предпочтение будет отдано первому найденному правилу. Каждая строка описания правила аудита системных вызовов имеет следующий синтаксис -а ,

В качестве параметра указывается список событий, в который добавляется данное правило. К таким спискам относятся списки task (используется для ведения событий, связанных с созданием процессов), user (используется для ведения событий, в которых указываются параметры пользовательского пространства, такие как uid, pid и gid), exclude (используется для запрета аудита указанных в данном списке событий), entry (используется для регистрации событий системных вызовов) и exit (используется для регистрации событий системных вызовов).

В качестве параметра указывается одно из действий, предпринимаемых по отношению к указанным в списках событиям. Доступно всего два действия: never и always. Пи указании действия never, события не записываются в журнал аудита. Указание действия always имеет противоположный эффект.

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

Добавлять правила в данный файл можно также при помощи команды auditdctl, используя ключ -а. При этом правила, добавляются в конец файла auditd.conf. Для того, чтобы добавить правило в начало данного файла, необходимо использовать ключ -А.

-a exit,always -s open -f uid=502 -f key=502open

-a entry,always -s chown

В первом случае задается правило, которое фиксирует все события, связанные с системным вызовом open, выполняемым от пользователя с идентификатором 502. Записи, удовлетворяющие данному условию, помечаются в файле audit.log меткой 502ореп. Во втором случае задается правило, которое фиксирует все системные вызовы chown.

Когда заданное в правиле действие будет выполнено, результат его выполнения заносится в журнал /var/log/auidt/auidit.log.type=PATH msg=audit(1233260763.459:334): item=0 name="/etc/passwd" inode=852389 dev=08:02 mode=0100644 ouid=0 ogid=0 rdev=00:00

type=SYSCALL msg=audit(1233260763.460:335): arch=40000003 syscall=5 success=yes exit=3 a0=928e350 al=8000 a2=0 a3=8000 items=l ppid=3529 pid=3551 auid=0 uid=502 gid=502 euid=502 suid=502 fsuid=502 egid=502 sgid=502 fsgid=502 tty=ptsl comm="vim" exe="/usr/bin/vim" key="502open"

Помимо слежения за системными вызовами, система аудита ОС Linux позволяет следить за доступом к файлам и каталогам. Для этого в файле auidt.rules необходимо создать правило имеющее следующий синтаксис:

-w -к

В параметре указывается полный путь к файлу или каталогу, за которым необходимо следить. Параметр -к используется для пометки всех событий, связанных с доступом указанному файлу. Это позволяет быстро находить интересующую информацию в журнальном файле. В следующем примере приведены два правила, в которых осуществляется слежение за файлами в каталоге /etc/sysconfig, а также слежение за доступом к команде iptables:

-w /etc/sysconfig -k sysconfig

-w /sbin/iptables -k iptables -p x

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

Для управления правилами, помимо редактирования конфигурационного файла audit.rules, можно использовать команду auditctl. Для просмотра активных правил аудита необходимо выполнить команду auditctl -l. Для определения статуса системы аудита необходимо выполнить команду auditctl -s.

Обычно журнальный файл системы аудита событий ОС Linux можно просматривать при помощи любого текстового редактора. Однако для выполнения общего анализа событий требуется суммировать отдельные записи в данном файле, что практически нереально выполнить, используя только возможности текстового редактора. Для выполнения анализа и отображения статистики аудита событий в состав пакета audit входят утилиты ausearch и aureport. Утилита ausearch может выполнять поиск записей аудита на основе различных критериев поиска, таких как имя файла, идентификатор пользователя, название системного вызова и прочее. Утилита aureport используется для формирования отчетов на основе журнального файла аудита audit.log.

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

Система аудита позволяет следить за выполнением определенного процесса, используя утилиту autrace . Это особенно полезно при поиске проблем.



3.1.2 Авторизация пользователей(FIA)

Авторизация пользователя в самой системе для использования ее локальных ресурсов. Что собой представляет авторизация? В отличие от доступа к файлам, во время авторизации осуществляется проверка доступности для пользователя определенного сервиса, предоставляемого системой, например сервиса login для входа в систему или сервиса удаленного копирования файлов ftp. Можно разрешить одному пользователю копировать файлы, но в то же время запретить использовать login, другому, наоборот, запретить пользоватся ftp, но предоставить возможность отправлять почту.

Первым делом во всех этих случаях осуществляется проверка соответствия имени пользователя и пароля. Если данный этап пройден, следует проверка доступности сервиса. Типичной является ситуация, когда записи о пользователях находятся локально в файле паролей. В этом случае проверка соответствия производится по нему.

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

Мы не будем уделять внимание ситуации, когда сервис также производит и проверку соответствия, так как это - пагубная практика, имеющая смысл лишь при условии предоставления одного публичного сервиса. Система производит проверку соответствия на основании файла паролей /etc/passwd, в котором хранятся необходимые атрибуты пользователя; этот файл доступен только для чтения. Сами пароли хранятся отдельно в файле /etc/shadow, точнее даже не пароли, а их уникальные необратимые хэши. Этот файл не доступен ни для чтения, ни для записи никому, кроме «суперпользователя» (суперпользователь или root - вообще уникальная личность в мире Linux).

Угроза безопасности в данном случае состоит, собственно, в модификации файла /etc/passwd, так как формат файла предусматривает наличие у пользователя беспарольного доступа, а также содержит информацию об уровне прав в системе, наличие уровня 0 - означает полный контроль над системой. Однако не стоит преувеличивать эту угрозу. Как правило, изменения в файле легко обнаруживаются, да и изменить его - не такая уж тривиальная задача, так как правами его изменения обладает только «суперпользователь». Чтобы постороннее воздействие обнаружилось не слишком поздно, существуют описанные выше средства проверки целостности ФС, поэтому опытные взломщики-рецидивисты предпочитают не трогать этот файл, а используют так называемые backdoors: после взлома системы устанавливают сетевой сервис на каком-либо доступном сетевом порту, который позволяет им беспрепятственно воспользоваться системой в любое время, не зная пароля. Об этом речь пойдет ниже, при рассмотрении проблем сетевой безопасности.

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

Как уже говорилось выше, в большинстве дистрибутивов Linux есть средства автоматической проверки изменений.



3.1.2.1 РАМ

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

Трудность заключается в синхронизации записей о пользователях для разных систем. Кроме того, приходится следить за несколькими копиями файла паролей и периодически вносить в них изменения. Естественно, в такой ситуации возникает большая вероятность ошибок со стороны администратора.

К счастью, в Linux имеется реализация PAM (Pluggable Authentication Modules), благодаря которой можно организовать централизованное хранение записей о пользователях, причем совершенно необязательно в этом случае иметь запись о пользователе в файле паролей (/etc/passwd). Благодаря модульности система позволяет проводить авторизацию из различных источников. Кроме того, архитектура PAM такова, что позволяет организовать стек из модулей и таким образом обеспечить многоуровневую систему авторизации. В РАМ реализованы все средства для организации полноценной авторизации пользователя, включая проверку доступности сервиса. Таким образом, отпадает необходимость проводить подобные проверки самим сервисом.

Естественно, чтобы использовать PAM, необходима поддержка его в самом приложении (в данном случае - сервисе). В настоящее время поддержка PAM реализована в большинстве используемых сетевых сервисов, поставляемых вместе с дистрибутивами Linux. В PAM существуют такие понятия, как auth (аутентифиация), account (авторизация), session (сессия) и password.

Для чего используется подобное разделение:

auth проводит проверку валидности пользователя и предоставляет данные, связанные с пользователем (например, домашний каталог);

account проводит проверку доступности сервиса, проверку источника запроса (например, если используется ограничение по сетевым адресам), проверку времени и т. д.;

session позволяет управлять сессией после авторизации пользователями старта сервиса (может быть полезным, если необходим контроль времени использования сервиса или в иных случаях);

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

Для РАМ в настоящее время доступно огромное количество модулей, в том числе pam_ldap - для авторизации из сервера директории, pam_krb - для использования kerberos, pam_radius - для использования radius-серверов и многие другие. Все они позволяют организовать безопасную и удобную в обслуживании информационную инфраструктуру.

3.1.2.2 Сервисы авторизации

Так как выше были описаны способы авторизации в Linux, и в том числе с использованием внешних хранилищ информации о пользователях, следует хотя бы вкратце перечислить, какие из них доступны в ОС Linux. Таковыми являются практически все промышленные стандарты, к которым можно отнести radius (freeradius, icradius), tacacs, kerberos версии 4 и 5 (krb4), ldap (openldap). В данной статье мы не будем затрагивать способ авторизации с использованием NIS, так как, на мой взгляд, он не делает жизнь безопаснее и не облегчает работу по обеспечению защиты системы.



3.1.3 Отказоустойчивость

ОC Linux без всяким сомнений является самой отказоустойчивой на сегодняшний день.

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

Наиболее эффективный метод избыточностив --аппаратная избыточность, достигается путем резервирования.

Mdadm - утилита для управления программными RAID массивами в Linux (Linux Software Raid), ранее известная, как mdctl. MD -- сокращение от Multiple Devices.

RAID1 - (mirroring) -- зеркалирование, то есть запись одних и тех же данных одновременно на несколько дисков, что обеспечивает отказоустойчивость при выходе из строя любого количества дисков, пока остаётся хотя бы один работоспособный.

3.2 Вторая группа функциональных требований к ОС в соответствии стандартам ISO

3.2.1 Связь - сетевая безопасность (FCO)

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

Ядро ОС Linux реализует сетевой и транспортный уровни модели OSI, но наибольший интерес для нас представляет стек TCP/IP и организация работы с ним. Рассматривая сетевую безопасность, мы имеем в виду возможности ОС Linux по обеспечению защиты сетей, а не самой себя в сети. Потенциальная угроза сетям заключается в доступе к информации, хранящейся на компьютерах сети и передаваемой в сети или между сетями информации. Можно разделить методы достижения этих целей злоумышленниками или просто случайными людьми. В первом случае для доступа к хранящейся на компьютерах информации необходимо получить контроль над машиной, во втором - над средой передачи данных. Они тесно взаимосвязаны, однако имеют принципиальные различия как в получении контроля над ними, так и в обеспечении их защиты.

3.2.2 Приватность (FPR)

В Windows от Microsoft и OS X от Apple ситуация является беспросветной. Эти производители никогда не откажутся от слежки за населением. В частности, летом 2013-го выяснилось, что корпорация Microsoft сообщала местным спецслужбам о дырах в ОС, неизвестных общественности.

В Linux «из коробки» наличествуют шпионские модули только в Unity. Когда пользователь что-либо набирает в поиске Dash, информация отправляется в Canonical (фирму, изготавливающую Ubuntu), а оттуда -- в Amazon. Причём, Canonical не скрывает наличия сей функциональности, оную даже можно отключить, легко отыскав в настройках. Впрочем, лучше не отключать, а удалить cсовсем пакеты unity-lens shopping, unity-scope-musicstores и unity-scope-video-remote. Других «закладок» в Linux не имеется.

3.2.3 Защита данных пользователя (FDP)

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

Безусловно, что для повышения конфиденциальности полезно хранить данные на дисках в зашифрованном виде. Для обеспечения сквозного шифрования всей файловой системы в Linux используются криптографические файловые системы CFS (Cryptographic File System) и TCFS (Transparent Cryptographic File System).

3.2.4 Анализ уязвимостей (FPT)

Анализ средств по обеспечению безопасности ОС Linux

Много копий было сломано в спорах о том, действительно ли Linux -- более безопасная операционная система,

а) Серьезность уязвимостей в системе безопасности, которая оценивается по следующим показателям:

o - возможный ущерб (насколько велик вред от использования ОС с незакрытой уязвимостью?);

o - возможность использования (насколько легко использовать данную уязвимость?);

o - возможная доступность (какого рода доступ требуется для использования данной уязвимости?).

б) Количество уязвимостей, серьезность которых определяется как Критическая.Результаты сравнения не оказались неожиданными. Даже по субъективным и заниженным стандартам, применяемым Microsoft, по меньшей мере 38% последних программных коррекций предназначены для ликвидации брешей, которые Microsoft относит к критическим. Только 10% программных коррекций и предупреждений в Red Hat относятся к брешам, имеющим критический уровень серьезности. Приведенные результаты получены при условиях, благоприятных для Microsoft и обоснованно жестких для Red Hat, так как они основаны на критериях Microsoft, а не на используемых нами более строгих показателях безопасности. Если применить наши собственные критерии, то количество критических брешей в Windows Server 2003 возрастет до 50%. Результаты запроса к базе данных Computer Emergency Readiness Team (CERT) подтвердили наши выводы, сделав разницу еще более значительной. Расположив полученные данные по убыванию серьезности (от более критических к менее критическим), мы обнаружили, что уровень серьезности 39 из первых 40 записей в базе данных CERT для Windows превышает пороговое значение, установленное CERT.

3.3 Третья группа функциональных требований ISO к ОС

3.3.1 Криптографическая поддержака ( FCS)

Я не буду подробно останавливаться в этом пункте на поддержке шифровани ОС Линукс, так как используемые механизмы шиврования уже были описаны в пункте 3.2.3 Защита данных пользователя(FDP) курсовой работы. Хочу только дополнительно сказать о шифровании паролей.

Шифрование паролей.

В Linux для шифрования паролей традиционно используется алгоритм DES. Зашифрованный пароль обычно помещается в файл /etc/passwd. При попытке пользователя зарегистрироваться в системе введенный им пароль шифруется и затем сравнивается с записью в парольном файле. При совпадении система разрешает доступ. В программе шифрования паролей используется однонаправленное шифрование (достигается за счет того, что ключом для шифрования пароля является сам пароль). К сожалению, в настоящее время алгоритм DES уязвим к атаке со стороны мощных компьютеров (использование прямого перебора или подбора в большинстве случаев приводит к отгадыванию паролей). Поэтому для Linux были разработаны дополнительно к шифрованию еще два мощных механизма защиты.

Механизм «теневых паролей»

Суть этого механизма проста: парольный файл, даже зашифрованный, доступен только системному администратору. Для этого он помещается в файл /etc/shadow, права на чтение которого принадлежат только суперпользователям. Для реализации подобной схемы защиты в Linux используется набор программных средств Shadow Suite. В большинстве дистрибутивов Linux механизм «теневых паролей» по умолчанию не задействован (кроме, пожалуй, RedHat). Но именно Linux выгодно отличает наличие новейшего механизма, с помощью которого можно легко организовать мощную систему защиты. Это технология подключаемых модулей аутентификации ( PAM .п 3.1.2.1.)

3.3.2 FTA -- доступ к объекту оценки (управление сеансами работы пользователей)

Управление сеансами пользователей выполняется суперпользователем локально или централизованно через контролируемый домен сервером безопасности.

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

Раньше данная проблема решалась достаточно просто: при обладании паролем root можно было зайти в систему под его аккаунтом либо временно получить его права, используя команду su. Потом выполнить все необходимые операции и вернуться обратно под обычного пользователя. В принципе, такая схема работает неплохо, однако у неё есть много существенных недостатков, в частности, невозможно никак (точнее, очень сложно) ограничивать административные привилегии только определённым кругом задач.

Поэтому в современных дистрибутивах Linux вместо root аккаунта для администрирования используется утилита sudo.

Что такое sudo.

Sudo -- это утилита, предоставляющая привилегии root для выполнения административных операций в соответствии со своими настройками. Она позволяет легко контролировать доступ к важным приложениям в системе. По умолчанию, при установке Ubuntu первому пользователю (тому, который создаётся во время установки) предоставляются полные права на использование sudo. Т.е. фактически первый пользователь обладает той же свободой действий, что и root. Однако такое поведение sudo легко изменить, об этом см. ниже в пункте про настройку sudo.

Где используется sudo.

Sudo используется всегда, когда вы запускаете что-то из меню Администрирования системы. Например, при запуске Synaptic вас попросят ввести свой пароль. Synaptic - это программа управления установленным ПО, поэтому для её запуска нужны права администратора, которые вы и получаете через sudo вводя свой пароль.

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

3.3.3 Доверенный канал (FTP)

Виртуальные частные сети.

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

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

Таким образом мы получаем защищенный криптотунель с удаленным пользователями и серверами.



4. Безопасность ядра ОС Linux

Помимо функциональных требований немогу упустить из вида безопасность ядра операционной системы.

Основная задача ядра системы - обеспечение выполнения процессов в системе, организация разделения времени и ресурсов, в том числе оперативной памяти. Перед загрузкой ядру Linux можно передать параметры загрузки, которые могут изменить нормальный режим загрузки. В частности, в ядре имеется возможность загрузки с заданием инициализационного процесса, отличного от стандартного init. Инициализационный процесс - это первая программа, которая выполняется после загрузки ядра. Стандартный процесс init выполняет загрузочные сценарии и запускает сервисы, в частности запускает процессы getty для терминальных линий и виртуальных консолей. Это важный момент обеспечения безопасности, так как процессы getty (в популярных дистрибутивах Linux, как правило, используется вариант mingetty, mgetty или agetty) организуют доступ к системе с обслуживаемых ими консолей.

Изменение режима загрузки, как правило, необходимо в случае аварийного восстановления системы или иногда используется в вариантах ОС Linux для встраиваемых систем. В случае физического доступа к компьютеру посторонних лиц потенциально существует опасность изменить параметры загрузки и получить неограниченный доступ к системе. Для предотвращения подобной опасности применяется парольная защита в менеджерах загрузки ОС. Стандартные загрузчики Linux (grub и lilo) имеют такую возможность, кроме того, grub может хранить пароли загрузки в зашифрованном виде.

Следующий важный момент - собственно работа самого ядра системы. Ядро системы имеет полный доступ и контроль над ресурсами компьютера. Поэтому данные и код ядра системы в памяти отделены от остальных процессов. Таким образом, в ОС Linux реализованы два уровня выполнения: нулевой (уровень ядра) и первый (уровень прикладных процессов). Кроме того, Linux поддерживает сегментирование памяти, и прикладные процессы также отделены друг от друга и выполняются каждый в своем виртуальном адресном пространстве. Здесь следует заметить, что типичная и наиболее распространенная угроза системе при такой архитектуре исходит от ошибок, связанных с переполнением буфера. Однако эта особенность не является исключительно прерогативой ОС Linux, а присуща операционным системам, работающим на компьютерах с общей физической памятью данных и кода, то есть практически для всех современных многозадачных операционных систем. Вообще говоря, прямой доступ к памяти за пределами сегмента в Linux вызывает исключение, и программа останавливается.

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

Что касается ошибок в прикладных программах, то здесь также применимо все, что сказано по поводу ядра. В случае если программа разрабатывается самостоятельно, то существуют средства предварительной проверки кода на наличие потенциальных ошибок и дыр. В данном случае акцент следует ставить на слове «существуют», так как ошибки в программах не являются исключительной особенностью GNU/Linux, но для ОС Linux существуют средства проверки кода. Конечно, они имеются и для других ОС, но суть все же не в этом. Среди наиболее известных и доступных бесплатных средств проверки исходного кода для Linux можно назвать flowfinder, its4 и RATS. Все они предназначены для проверки программ, написанных на языке C, так как ошибки переполнения буфера и доступа к памяти в основном возникают при программировании именно на нем.

Другой довольно эффективный способ предотвращения фатальных ошибок при разработке программ для ОС Linux - использование языков высокого уровня. Здесь также следует выделить именно доступность компиляторов и интерпретаторов практически всех существующих языков программирования в ОС Linux и обширные библиотеки ПО.



5. Разграничение доступа

А так же не могу не сказать о разграничении доступа.

Так как Linux - многозадачная и многопользовательская ОС, в ней должны быть реализованы механизмы разграничения доступа. Как уже говорилось выше, этим занимается ядро системы. Все процессы в системе выполняются от имени и с правами некоего пользователя (возможно, хакера) и группы (хакеров). Под пользователем и группой в данном случае имеется в виду не конкретный человек, который знает пароль, а некая абстракция. Точнее сказать так: процесс существует в системе с некоторыми правами. Так как в системе Linux все представлено в виде файлов, то и права процесса, по сути, определяют доступность для него того или иного файла. Права эти описаны в индексах файлов. У каждого файла имеется описание режима доступа к нему для трех типов процессов: выполняемых от имени владельца файла, выполняемых не от имени владельца, но от имени владельца группы файла и для процессов вообще не имеющих никакого отношения к владельцам файла.

Работа реального человека с компьютером так или иначе заключается в создании многочисленных нужных (xchat, например) и не совсем процессов. Поэтому очевидно, что каждый реальный пользователь имеет уникальный номер и все его процессы и созданные ими файлы обладают одинаковым, пользовательским, номером. В этом суть разграничения доступа.

Такой способ разграничения - наследие Unix. Можно сказать, что он несколько устарел, если рассматривать его в рамках какой-либо распределенной информационной среды, но это не суть важно, так как использование acl или dacl (списки доступа) с точки зрения безопасности имеет в основном те же проблемы. Потенциальная опасность здесь заключается в неверной установке прав доступа к файлам и каталогам, не предназначенным для посторонних. Это может относиться к секретной переписке по e-mail начальника или доступе к базе данных паролей. Конечно, подобные промахи, как правило, на совести администратора системы. Но даже очень квалифицированный специалист не в состоянии отследить все файлы в системе, количество которых может превышать десятки и даже сотни тысяч, и права доступа к ним. Для решения подобных проблем существует несколько способов, один из которых - использование средств проверки целостности файловой системы.



6. Традиционные способы защиты, используемые в Linux

Традиционные способы защиты ОС в основном связаны с физической безопасностью. Физическая безопасность - это первый уровень безопасности, который необходимо обеспечить для любой компьютерной системы. Причем к очевидным методам обеспечения физической безопасности относятся замки на дверях, кабели в коробах, закрытые ящики столов, средства видеонаблюдения и т. п. Для усиления этих проверенных временем мероприятий можно использовать также компьютерные замки различных конструкций, основное назначение которых сводится к следующему:

- предотвращение хищения компьютера и его комплектующих;

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

- прерывание работы компьютера при вскрытии корпуса;

- блокировка работы с клавиатурой и мышью.

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

Некоторые загрузчики Linux позволяют установить пароль, запрашиваемый при загрузке системы. Так, при работе с LILO (Linux Loader) можно использовать параметры (позволяет установить пароль для начальной загрузки) и (разрешает загрузку после указания определенных опций в ответ на запрос LILO).