Вокруг ОС UNIX вообще и ее защищенности в частности существует множество домыслов и слухов, не имеющих отношения к современному состоянию дел. Большинство аргументов, используемых противниками ОС UNIX, относится к старым, вышедшим из употребления версиям и почерпнуто из книг, а не из собственного опыта. Тем не менее с середины 80-х годов, вместе с расширением сферы действия ОС UNIX, во многих ее клонах стали активно развиваться и средства безопасности. Как оказалось, изначально заложенные в ОС средства защиты данных, а именно идентификация пользователей и разграничение доступа, могут быть доработаны, с тем чтобы послужить основой для проведения корпоративной политики безопасности. Сегодня можно утверждать, что в большинстве ОС подобная доработка завершена и по всем параметрам Unix соответствует классу безопасности C2, причем в его современной трактовке. Докажем это утверждение на примере одной из реализаций операционной системы Unix-ОС Solaris 2.x.
Оппоненты ОС Unix действительно правы в той части своих претензий, что данная операционная система, одним из вариантов которой является ОС Solaris, первоначально создавалась для разработчиков программного обеспечения, совместно реализующих какой-либо проект, когда вопросы удобства работы и взаимодействия обычно преобладают над иными требованиями к ОС. Однако с середины 80-х годов вместе с расширением сферы действия этой ОС стали активно развиваться и средства безопасности.
Большое число публикаций по вопросам безопасности в ОС UNIX говорит скорее о популярности этой операционной системы, а не о ее беззащитности. Естественно, что в ОС UNIX, как и в любой другой большой системе, время от времени находятся ошибки, часть из которых может быть использована злоумышленниками. Однако, как правило, компании и разработчики обычно достаточно быстро реагируют на сообщения об ошибках, так что легальные пользователи могут в короткий срок, не дожидаясь выхода новой версии, наложить заплатку. Правда, от системного администратора требуется определенный уровень квалификации и активности, но этими атрибутами должен обладать любой специалист по информационной безопасности.
Концепция построения многоуровневой системы защиты на основе ОС Solaris
Обеспечение безопасности современной информационной системы требует проведения целого комплекса мероприятий в соответствии с разработанной на предприятии политикой информационной безопасности.
Существует два возможных направления политики информационной безопасности. В первом случае - ограничительная политика, пользователь имеет право использовать любые ресурсы, кроме тех, доступ к которым ограничен или закрыт. Во втором случае - нормативная политика, пользователь имеет право использовать только те ресурсы, которые ему явным образом выделены. Первая схема применяется, как правило, на предприятиях с большим набором функционально различных групп квалифицированных пользователей. Вторая схема - там, где много действий выполняется с одним и тем же набором приложений, причем круг этих приложений может быть очерчен заранее, а любое нестандартное действие рассматривается как попытка нарушения режима информационной безопасности.
Как показывает статистика, нарушения информационной безопасности возникают как в результате умышленных (25%), так и в результате случайных ошибочных действий (52%). При этом на легальных пользователей информационной системы приходится более 80% нарушений. Хотя приведенные цифры могут приниматься во внимание лишь в статистическом контексте - даже маловероятное нарушение в одном конкретном случае может произойти, и, кроме того, отсутствуют сведения о распределении по ущербу, нанесенному информационной системе, они дают определенные основания для выработки главных направлений политики безопасности.
Говоря о безопасности информационной системы, необходимо учитывать следующие соображения.
Во-первых, никакая информационная система не будет удовлетворительно защищена без продуманного плана построения такой защиты и четкой политики безопасности предприятия. При этом программно-технические средства защиты должны рассматриваться только как один из компонентов, вместе с правовыми, административными, физическими мерами.
Во-вторых, при проектировании защиты информационной системы необходим анализ рисков, существенных для данного предприятия.
В-третьих, система информационной безопасности должна строиться по принципу разумной достаточности. Необходимо помнить, что всякая защита требует затрат как материальных, так и информационных ресурсов, причем их объем быстро растет при усилении защищенности.
В-четвертых, хотя встроенные средства обеспечения безопасности ОС могут и должны применяться для защиты информационной системы в целом, в силу своей специфики их необходимо дополнить в соответствии с требованиями к конкретной конфигурации.
Наконец, необходимо отдавать себе отчет в том, что в хорошей системе риск информационных потерь минимизирован, но не исключен. Поэтому действия, требующиеся для восстановления ресурсов информационной системы в случае нарушения каких-либо аспектов безопасности, должны составлять неотъемлемую часть защитных мероприятий. В соответствии с принятой терминологией информационная безопасность обеспечена в случае, если для любых информационных ресурсов в системе поддерживается определенный уровень конфиденциальности, целостности и доступности. При этом должна учитываться не только вероятность нарушения какого-либо из аспектов безопасности в результате умышленных либо неумышленных действий пользователя, но и вероятность выхода из строя каких-либо узлов информационной системы. В этом смысле средства повышения надежности элементов информационной системы также входят в комплекс информационной безопасности предприятия. Невозможно анализировать безопасность информационной системы без рассмотрения ее структуры, которая достаточно хорошо описывается четырехуровневой моделью со следующим набором уровней:
1. Внешний уровень, определяющий взаимодействие информационной системы организации с глобальными ресурсами и системами других организаций. Функционально этот уровень характеризуется, с одной стороны, сетевыми сервисами, предоставляемыми данной организацией, с другой стороны, аналогичными сервисами, запрашиваемыми из глобальной сети. На этом уровне должны ограничиваться как попытки внешних пользователей несанкционированно получить от организации дополнительный сервис, так и попытки собственных пользователей осуществить подобные операции по отношению к внешним сервисам или несанкционированно переслать информацию в глобальную сеть.
2. Сетевой уровень связан с доступом к информационным ресурсам внутри локальной сети организации. Безопасность информации на этом уровне обеспечивается средствами проверки подлинности пользователей и разграничением доступа к ресурсам локальной сети (аутентификация и авторизация).
3. Системный уровень связан прежде всего с управлением доступа к ресурсам ОС. Именно на этом уровне происходит непосредственное взаимодействие с пользователями и, самое главное, определяются "правила игры" между информационной системой и пользователем - задается либо изменяется конфигурация системы. В этой связи естественно понимать защиту информации на данном уровне, как четкое разделение, к каким ресурсам ОС какой пользователь и когда может быть допущен. Защите системных ресурсов должно уделяться особое внимание, поскольку несанкционированный доступ к ним может сделать бессмысленными прочие меры безопасности.
4. Уровень приложений связан с использованием прикладных ресурсов информационной системы. Поскольку именно приложения на содержательном уровне работают с пользовательскими данными, для них нужны собственные механизмы обеспечения информационной безопасности.
Средства защиты, встроенные в ОС, занимают особое место. Их основной задачей является защита информации, определяющей конфигурацию системы, и уже затем - пользовательских данных. Такой подход представляется естественным, поскольку возможность изменять конфигурацию делает механизмы защиты бессмысленными. Так как эти ресурсы находятся на системном уровне, можно было бы ожидать, что здесь и будут собраны основные встроенные средства защиты информации. В случае ОС Solaris 2.x, рассматривающей распределенные решения для информационных систем, встроенные средства защиты продвинуты на сетевой уровень, а в общем наборе решений, предоставляемых для корпоративных информационных сетей, присутствуют также инструменты безопасности внешнего уровня. Кроме того, поскольку для информационной безопасности существенным является обеспечение доступности данных, ряд компонентов в составе ОС Solaris 2.x, не являясь средствами защиты в классическом смысле, тем не менее существенны.
Системные средства аутентификации пользователей
Первое, что должна проверить операционная система в том случае, если она обладает хотя бы минимальными средствами защиты, - это следует ли ей иметь дело с субъектом, который пытается получить доступ к каким-либо информационным ресурсам. Для этого существует список именованных пользователей, в соответствии с которым может быть построена система разграничения доступа.
Имена пользователей представляют собой относительно доступную информацию. В этой связи представляется разумным запросить у потенциального пользователя некоторую дополнительную информацию, пароль, удостоверяющий, что он тот, за кого себя выдает. Эта процедура называется аутентификацией. Предполагается, что субъект, способный сообщить системе имя и соответствующий ему пароль, является легальным пользователем. Здесь очень существенной оказывается политика управления пользовательскими паролями, определяющая правила их назначения, хранения, изменения и другие связанные с этим вопросы. Чем большие возможности по проведению подобной политики предоставляет администратору операционная система, тем больше шансов на то, что парольная аутентификация будет действенным инструментом защиты. Для иллюстрации важности разумной политики назначения пользовательских имен и паролей можно привести данные исследований, проведенных в AT&T, показывающие, что из 500 попыток несанкционированного доступа около 300 составляют попытки угадывания паролей или беспарольного входа по пользовательским именам guest, demo и т.д.
Формулируя требования к паролю, необходимо указать, какой набор символов может служить надежным паролем, а какой - нет. Очевидно, что пароли, которые легко угадать либо быстро подобрать, лучше не использовать. В "черный" список включаются имя, отчество и фамилия пользователя, дата рождения, номер телефона, слова, относящиеся к области его интересов, а также общеупотребительные слова, подбираемые по словарю. Лучшим паролем с точки зрения неугадываемости является случайный бессмысленный набор символов. К сожалению, запомнить такой набор достаточно сложно, что заставляет пользователя записывать его на бумаге, с риском потерять запись либо случайно показать ее кому-либо. Разумной альтернативой является пароль, составленный из первых букв каждого слова какой-либо легко запоминающейся фразы. Еще более надежное средство - применение программных генераторов паролей, порождающих случайные и бессмысленные, но благозвучные, а потому запоминающиеся сочетания.
Даже удачные пароли с течением времени становятся известными. Это заставляет периодически проводить их замену. Считается, что в информационных системах с низкими требованиями к обеспечению безопасности пароль должен меняться каждые три месяца, а по мере увеличения значимости вопросов, связанных с несанкционированным доступом, указанный срок уменьшается до шести недель. Не менее важно и минимально допустимое время между двумя последовательными изменениями паролей, поскольку такое изменение - типичное действие в случае получения кем-либо несанкционированного доступа к системе либо ресурсам пользователя. Утилиты Solaris 2.x предоставляют администратору возможность контролировать процесс изменения паролей. Системный администратор может назначать минимальное и максимальное время между изменениями пароля с выдачей предупреждения пользователю о необходимости изменить пароль и блокированием доступа в систему в случае неподчинения.
В любой большой системе имеются пользователи с временными правами доступа. По окончании легальной работы такого пользователя его системный счет должен быть уничтожен, в противном случае он может использоваться в дальнейшем, но уже несанкционированно. Для предотвращения такой ситуации в Solaris 2.x возможна установка времени испарения пароля, после которого автоматический доступ пользователя в систему прекращается.
Наличие пользователей, реально не работающих в системе, создает опасность запоздалой диагностики несанкционированного использования доступных им ресурсов. Чтобы избежать этого, в Solaris 2.x может быть определено максимальное время существования неактивного пользователя, по истечении которого пароль блокируется и пользователь может получить доступ к системе только с помощью системного администратора.
При обеспечении режима безопасности важны не только средства предохранения от несанкционированного доступа, но и средства выявления таких событий. Операционная система Solaris 2.x предусматривает ведение записей неудачных попыток входа в систему. Эту информацию нетрудно использовать для оповещения системного администратора в случае, если количество таких попыток превышает заданную величину.
Одной из распространенных угроз безопасности информационной системы является терминал, оставленный пользователем без присмотра во время работы. В качестве контрмеры можно автоматически блокировать доступ либо прерывать сеанс работы в системе спустя некоторое время после прекращения активности пользователя. Это достигается применением в качестве пользовательского командного интерпретатора программы tcsh, имеющей соответствующие установки.
Поскольку ОС Solaris является многооконной средой, автоматический выход из системы должен заменяться закрытием экрана. Имеющаяся в составе ОС утилита xlock позволяет закрывать экран X-терминала или рабочей станции с последующим открытием при введении пароля. Эта программа должна быть запущена пользователем перед тем, как он покидает рабочее место. Существуют утилиты, позволяющие проводить закрытие экрана автоматически, однако применять их не рекомендуется, поскольку при этом создается возможность установки программы, эмулирующей закрытие экрана и считывающей пользовательский пароль.
Особую опасность представляет удаленный вход в систему через телефонную сеть. Поскольку контролировать эту сеть невозможно, то необходимы дополнительные меры безопасности - в Solaris 2.x это установка дополнительных паролей на последовательные порты.
Существенным моментом является степень защищенности самой информации о пользователях и их паролях, которые хранятся в зашифрованным виде в файле /etc/shadow. В отличие от файла /etc/passwd, /etc/shadow доступен на чтение только при наличии у пользователя привилегий системного администратора. Это важно, так как одним из типичных приемов "взлома" системы является копирование злоумышленником на свой компьютер файла паролей и их подбор различными методами.
Разграничение доступа пользователей к ресурсам
Для разграничения доступа к файлам в ОС Solaris применяются наборы из трех флагов, разрешающих, соответственно, чтение, запись и выполнение файла. При этом каждый файл имеет пользователя-владельца, который и устанавливает перечисленные флаги для себя, для членов своей группы и для прочих пользователей. Такой метод называется произвольным управлением доступом, поскольку владелец действует по своему усмотрению.
Стандартная команда ls -l выдает список файлов с правами доступа к ним, например:
-rwxr-xr- filename
Здесь символы "rwx" означают наличие прав на чтение, запись и исполнение соответственно, а символ "-" - отсутствие такого права. В данном случае владелец может читать, писать и выполнять файл, члены группы - читать и выполнять, прочие пользователи - только читать. Для каталогов флаг x означает право на поиск файлов.
Первоначальные права доступа при создании файлов задаются с помощью команды umask. Ее аргумент, трехзначное восьмеричное число, показывает, какие права будут маскироваться ("вычитаться"). Так, команда umask 027 приведет к тому, что создаваемые файлы будут иметь права доступа rwx для владельца, rx для группы, а прочие пользователи останутся без каких-либо прав по отношению к файлу. Правильная установка значения umask - важный элемент реализации политики безопасности в области разграничения доступа. Пользователь может изменять права доступа к своим файлам при помощи команды chmod.
Описанная схема позволяет строить достаточно надежные средства разграничения доступа к программам и данным, но ей недостает гибкости. Наличие всего трех видов субъектов доступа: владелец, группа, все остальные - затрудняет задание прав "с точностью до пользователя", особенно в случае больших конфигураций, начиная с версии Solaris 2.5 появилась возможность использовать списки управления доступом (Access Control List, ACL), позволяющие с помощью команды setfacl индивидуально устанавливать права доступа отдельных пользователей или групп. Наличие списка обнаруживается при помощи команды ls -l по символу + после стандартных для UNIX прав доступа. Например, для файла file1, принадлежащего пользователю user1 из группы group1, указанные действия будут выглядеть следующим образом:
ls -l file1
-rw-r-r-+ user1 group1 .... file1
Полную информацию по ACL дает команда getfacl. В рассматриваемом случае она выдаст следующую информацию:
getfacl file1
#file: file1 #owner: user1 #group:
group1 user::rw- user:user1:rw- user:
user2:-- group::r- other:r-
В данном примере отдельно для пользователя user2 запрещен любой доступ к файлу file1.
Механизм ACL работает как в локальных (UFS), так и в сетевых (NFS) файловых системах. Параметры списка доступа сохраняются также всеми встроенными средствами резервного копирования.
Среди всех пользователей особое положение занимает пользователь root, обладающий максимальными привилегиями. Обычные правила разграничения доступа к нему не применяются - ему доступна вся информация на компьютере.
Очевидно, пароль пользователя root должен выбираться и скрываться системными администраторами с особой тщательностью. В качестве дополнительной меры безопасности ОС Solaris 2.x позволяет запретить вход под именем root с потенциально ненадежных терминалов. При анализе регистрационной информации системным администраторам следует обращать особое внимание на все попытки входа под именем root и использования команды su.
По отношению к программам, переустанавливающим идентификатор пользователя, необходим контроль целостности и в плане прав доступа к программному файлу, и в плане его содержимого. Число таких программ желательно минимизировать и применять их только тогда, когда это действительно необходимо, например для программы login. В качестве инструмента контроля можно рекомендовать утилиту ASET.
Наличие нескольких путей получения повышенных привилегий является потенциально уязвимым местом в защите операционной системы. Особенно опасно, когда переустановка идентификатора пользователя производится не бинарным файлом, а программной командного интерпретатора (shell script), что объясняется легкостью ее модификации. Указанное обстоятельство заставляет администратора системы контролировать штатные пользовательские командные интерпретаторы, ограничивая возможности пользователя записями в файле /etc/shells. Поскольку большинство пользователей использует ограниченный набор приложений, в ряде случаев можно зафиксировать круг доступных программ, что особенно актуально при проведении нормативной политики безопасности предприятия. Для этого в Solaris 2.x предусмотрен "restricted shell" (ограничивающий системный интерпретатор). Свобода пользователя ограничивается пределами его каталога (в другой перейти нельзя) и возможностью использовать программы только из тех каталогов, которые записаны в переменной окружения PATH, причем изменение значения этой переменной не допускается. Кроме этого, пользователь не может задавать полные имена программных файлов и переназначать поток ввода-вывода.
В ряде случаев пользователь вообще не нуждается в непосредственном взаимодействии с операционной системой, работая постоянно с каким-либо приложением, например клиентом базы данных. В этом случае целесообразно использовать возможности разграничения доступа, предоставляемые СУБД. Чтобы реализовать ситуацию прямого входа в приложение app, необходимо создать следующий файл запуска командного интерпретатора (файл /etc/skeleton/.profile):
#/bin/sh trap 0 2 3 4 5 6
PATH=/home/bin;export PATH APHOME=/home; export APHOME exec
/home/bin/app exit
Команда trap позволяет не допустить прерывания стартового файла пользователем, который в рассматриваемом случае сможет работать исключительно с описанным приложением.
ASET - средство проверки корректности конфигурации системы
Операционная система Solaris имеет большое количество настроек и конфигурационных файлов, что позволяет адаптировать эту ОС для нужд конкретных пользователей информационной системы. Это, однако, создает опасность появления слабых мест, поэтому для проверки целостности и корректности текущей конфигурации в Solaris предусмотрена специальная утилита - ASET. Данная утилита запускает семь различных задач, каждая из которых выполняет набор специфических проверок, корректирует права доступа к файлам, и содержимое критичных с точки зрения безопасности конфигурационных файлов, а также осуществляет мониторинг критических областей ОС. Кроме собственно системного уровня, одна из задач проверяет допустимость использования машины в качестве входного компьютера в сеть предприятия (firewall).
ASET может быть настроена на один из трех уровней безопасности. На каждом последующем уровне доступ к ресурсам сокращается, делая систему более безопасной. На низшем уровне ASET проводит ряд проверок и только предупреждает о потенциально слабых местах в конфигурации ОС, не производя каких-либо корректировок. На следующем уровне ASET модифицирует некоторые системные файлы и параметры, ограничивая доступ в систему для уменьшения риска преодоления защиты. На самом высоком уровне ставится цель максимально ограничить возможности доступа в систему. При этом возможно изменение работы ряда системных сервисов.
При запуске программа ASET сначала проводит верификацию прав доступа к системным файлам. Следующая задача проверяет системные файлы и сравнивает их с описанием в мастер-файле программы ASET. Мастер-файл содержит установки, соответствующие избранному уровню безопасности. В ходе выполнения задачи для системных файлов проверяются владелец и группа, права доступа, размер и контрольная сумма, количество ссылок и время последней модификации. Список проверяемых программой ASET файлов находится в мастер-файле /usr/aset/masters/chklist и содержит более 1000 элементов. Указанный список может быть расширен по желанию системного администратора.
Далее проводится проверка корректности списка пользователей и их групп: контролируются дублирование имен и идентификаторов пользователей, формат файлов /etc/passwd и /etc/group, наличие паролей у всех пользователей и т.п., а также аналогичные параметры в NIS и NIS+.
После этого проверяются записи в конфигурационных файлах каталога /etc для выявления потенциально слабых мест в текущих настройках ОС. К числу таких файлов относятся /etc/default/login, /etc/hosts.equiv, /etc/inetd. conf, /etc/aliases, /etc/hosts, /etc/vfstab, /etc /dfs/dfstab, /etc/ftpusers и некоторые другие. На следующем этапе проверяются установки PATH и umask для пользователя root, находящиеся в файлах /.profile, /.login, /.cshrc. Дополнительно можно проверить, годится ли текущая конфигурация для экранирующей машины между локальной сетью предприятия и открытой глобальной сетью.
Результаты выполнения программы ASET записываются в текстовом виде в файлах директории /usr/aset/reports. Все корректировки, проводимые программой ASET, протоколируются, и систему можно в любой момент вернуть к прежнему состоянию, что страхует администратора от необратимых действий. Программу ASET рекомендуется запускать раз в сутки. Условия запуска ASET задаются переменной PERIODIC_SCHEDULE конфигурационного файла /usr/aset/asetenv.
BSM SunSHIELD - инструмент системного аудита
Вопросы информационной безопасности не могут успешно решаться, если нет средств контроля за происходящими событиями - только имея хронологическую запись всех производимых пользователями действий, можно оперативно выявлять случаи нарушения режима информационной безопасности, определять причины нарушения, а также находить и потом устранять потенциально слабые места в системе безопасности. Кроме того, наличие аудита в системе играет роль сдерживающего фактора: зная, что действия фиксируются, многие злоумышленники не будут совершать заведомо наказуемых действий.
Программные средства, осуществляющие такой контроль, называются средствами аудита. Поскольку в информационной системе предприятия присутствуют несколько функциональных уровней, на каждом из них желательно иметь средства мониторинга событий. Сегодня наличие механизмов аудита является обязательным требованием к крупным программным продуктам, работающим на любом из уровней. Что касается средств аудита ОС Solaris 2.x, то они принадлежат преимущественно системному уровню, лишь частично покрывая сетевой и тем более внешний функциональные уровни. Модуль SunSHIELD, входящий в состав Solaris 2.x, осуществляет аудит в соответствии с требованиями к классу безопасности C2, соответствующего пятому классу защищенности средств вычислительной техники по классификации Гостехкомиссии РФ.
Аудит невозможен без идентификации и аутентификации пользователей. С этой целью при входе в систему программой аудита пользователю присваивается уникальный идентификатор, ассоциируемый с пользовательскими процессами, который не меняется, даже если пользователь с помощью команды su меняет свое имя. Регистрационные действия выполняются специализированным аудит-демоном, который проводит запись событий в регистрационный журнал в соответствии с текущей конфигурацией. Аудит-демон стартует в процессе загрузки системы.
Каждое событие принадлежит какому-либо классу аудита. Такое деление упрощает анализ большого количества событий. Принадлежность событий к классам и набор классов могут быть сконфигурированы системным администратором путем редактирования файла /etc/security/ audit_event. Все события пронумерованы от 0 до 65535 - первые 2048 номеров отведены для событий, связанных с ядром ОС, номера с 2048 по 32767 - под пользовательские события ОС UNIX, а остальные - под прочие приложения. Таким образом достаточно легко производится настройка на круг событий, где требуется аудит.
В общем случае существует около двадцати классов отслеживаемых событий. Каждый класс имеет два имени - полное и сокращенное.
Для любого класса устанавливается один из трех флагов аудита: аудит в случае успешного выполнения действия, аудит неудачных попыток, безусловный аудит. Все указанные описания содержатся в файле /etc/security/ audit_control. Если желательно проводить аудит действий каких-либо пользователей в большем или меньшем объеме, чем всех остальных, администратору достаточно внести соответствующие изменения в файл /etc/security/audit_users.
Аудит-демон выполняется от имени суперпользователя. Соответственно, владельцем всех создаваемых им файлов является пользователь root. Даже если никаких классов для аудита не определено, аудит-демон постоянно работает, причем в каждый момент времени может существовать только один экземпляр демона. В случае, если проведение аудита наталкивается на какие-либо трудности, например исчерпание дискового пространства, аудит-демон с помощью программы audit_warn посылает соответствующее сообщение системному администратору.
При работе модулей аудита на нескольких машинах они могут администрироваться как части распределенной системы, когда каждая машина регистрирует события, а затем при помощи программы audit_reduce локальные регистрационные журналы собираются вместе, что позволяет анализировать все события, относящиеся к какому-либо классу или пользователю.
Все регистрационные журналы хранятся в бинарном виде. При необходимости они могут просматриваться при помощи программы praudit. Программа выводит содержимое журналов в текстовом виде в одном из трех вариантов: обычном, сокращенном или числовом.
Дополнительная особенность модуля BSM SunSHIELD - возможность резервирования внешних устройств за определенным пользователем. Это позволяет исключить, например, считывание информации с магнитной ленты в период, когда ее хозяин уже закончил работу с устройством, но ленту еще не снял.
Список классов аудита включает в себя:
| no_class -
file_read - file_write - file_attr_acc - file_attr_mod - file_creation - file_deletion - file_close - process - network - ipc - non_attrib - login_logout - application - ioctl - exec - other - |
исключается из классификации;
события, связанные с чтением/открытием файлов; модификация файлов; доступ к атрибутам файла; модификация атрибутов файла; создание объекта; уничтожение объекта; системный вызов close; операции, связанные с процессами: fork, exec и др.; сетевые события: доступ, контакт и т.д.; операции взаимодействия между процессами; события без атрибутов; administrative - действия администрирования; вход/выход пользователя; события, связанные с приложениями; системный вызов ioctl; выполнение программ; прочие события. |
Сетевые средства защиты
Защита информации на сетевом уровне имеет определенную специфику. Если на системном уровне проникнуть в систему можно было лишь в результате раскрытия пользовательского пароля, то в случае распределенной конфигурации становится возможен перехват пользовательских имени и пароля техническими средствами. Например, стандартный сетевой сервис telnet пересылает пользовательское имя и пароль в открытом виде. Это заставляет вновь рассматривать задачу аутентификации пользователей, но уже в распределенном случае, включая сюда и аутентификацию машин-клиентов. Высокая степень защиты достигается путем замены стандартных открытых сервисов на сервисы, шифрующие параметры пользователя/машины-клиента, чтобы даже перехват пакетов не позволял раскрыть эти данные. Наконец, немаловажное значение имеет аудит событий, происходящих в распределенной информационной среде, поскольку в этих условиях злоумышленник не столь заметен и имеет достаточно времени и ресурсов для выполнения своих задач.
Стандартные средства защиты, существующие в Solaris 2.x, не являются столь же объемлющими, что и на системном. Дело в том, что если на системном уровне однородность гарантирована и любые изменения могут вводиться достаточно эффективно, то в условиях локальной сети применяется, как правило, набор разнородного оборудования, функционирующего под управлением различных ОС, производители которых априорно не заинтересованы в соответствии средств этих систем концепции безопасности Solaris 2.x. Защита на сетевом уровне в данной ОС охватывает NIS+ и RPC (NFS). Дополняет указанные меры поддержка клиентской части сервера аутентификации Kerberos, что защищает такие "открытые" сервисы, как telnet и rlogin/rsh.
Защита информации в NIS+
Сетевой информационный сервис (NIS) служит для централизованного управления информационными ресурсами в распределенной среде. Строящий, подобно DNS-сервису, древовидную структуру имен объектов в сети, NIS+ функционально существенно богаче. Сервис NIS+ работает на основе набора таблиц, содержащих сведения о машинах, параметрах удаленной загрузки, паролях, ключах аутентификации машин локальной сети, пользователях и группах, подсетях, сетевых масках, адресах Ethernet, сервисах, протоколах, параметрах автоматического монтирования удаленных файловых систем и удаленного вызова процедур (RPC). Поскольку указанная информация является весьма важной с точки зрения безопасности информационной системы, ее надежная защита с учетом критериев конфиденциальности, целостности и доступности абсолютно необходима. Такая защита реализуется при задействовании механизмов авторизации и аутентификации NIS+.
Права доступа в NIS+ определяют, какие операции доступны тому или иному NIS-клиенту. Операции в NIS+ подразделяются на четыре класса: чтение (Read), модификация (Modify), создание (Create), удаление (Destroy). Каждое взаимодействие между клиентом и сервером может сводиться к запросу на проведение действий какого-либо из этих классов и соответственно авторизовываться. В NIS+ различаются четыре категории сетевых субъектов: владелец (Owner), группа владельца (Group), все (World), никто (Nobody), причем эти категории не совпадают с упоминавшимися выше категориями пользователей ОС Solaris и администрируются независимо.
В NIS+ имеется три уровня режима безопасности. Уровень 0 используется для тестирования и установки начального набора имен. В этом режиме любому пользователю NIS+ разрешен доступ к любому из объектов. Уровень 1 также применяется на стадии тестирования и отладки. В этом режиме используется тип аутентификации LOCAL, когда параметром служит идентификатор пользователя. В случае, если он не будет найден, клиенту предоставляются права Nobody. При этом все механизмы авторизации работают в полной мере. Наконец, на уровне 2 производится аутентификация клиентов NIS+ с использованием DES-ключей.
NIS+ разделяет клиентов, в зависимости от требуемого сервиса, на две категории: клиент-пользователь и клиент-машина. Клиент выступает как клиент-машина, если запрашиваемый им сервис предполагает получение полномочий привилегированного пользователя (root). Каждому клиенту соответствует удостоверение (credentials), при помощи которого и производится аутентификация. Удостоверение состоит из сетевого имени типа unix.UserID@domainname для клиента-пользователя либо unix.HostName@domainname для клиента-машины, а также поля верификации, с помощью которого проверяется подлинность и аутентичность удостоверения.
Все удостоверения NIS+ хранятся в одной из таблиц базы данных сетевого информационного сервиса, называемой "Cred table". Для каждого клиента в таблице содержится его имя, тип аутентификации, сетевое имя, открытый (public) и секретный (private) ключи. Удостоверение для каждого из клиентов создается администратором сети (домена сети). Сервер, обслуживающий NIS+, называется мастер-сервером.
Удостоверения клиентов создаются при помощи программы nisaddcred, которая формирует из идентификатора пользователя и имени домена сетевое имя, после чего заносит его в соответствующую таблицу. Для генерации ключей nisaddcred использует сетевой пароль клиента, который может и не совпадать с пользовательским паролем, записанным в файле /etc/shadow. На основании пароля генерируется пара 192-битных ключей в соответствии с алгоритмом Диффи-Хелмана. Ключи также заносятся в NIS+ таблицу.
При посылке запроса на NIS-сервер по умолчанию предполагается, что используется уровень безопасности 2. Если это оказывается не так, последовательно посылаются удостоверения уровней 1 и 0.
Перед генерацией удостоверений уровня 2 (DES-аутентификация) клиент обязан воспользоваться командой keylogin, предоставляющей доступ к его секретному ключу. Команда keylogin берет секретный ключ в таблице NIS+, расшифровывает его с помощью сетевого пароля и помещает в локальную базу данных. Клиент запоминает также открытый ключ сервера, необходимый для посылки последующих запросов.
В качестве первого шага аутентификации клиент по алгоритму Диффи-Хелмана генерирует DES-ключ и порождает временной штамп. Этот штамп кодируется DES-ключом и присоединяется к прочей информации, содержащейся в удостоверении клиента, образуя поле верификации. При проверке подлинности клиента сервер по сетевому имени отыскивает в таблице открытый ключ клиента. Затем, используя собственный секретный ключ и открытый ключ клиента, сервер генерирует DES-ключ, которым расшифровывает временной штамп, переданный в удостоверении. Если разница между временным штампом клиента и текущим временем находится в заданном интервале, аутентификация считается успешной.
Для подтверждения своей подлинности сервер возвращает клиенту временной штамп, увеличенный на единицу и зашифрованный аналогичным образом.
Рассмотрим теперь процедуру авторизации в NIS+. Как уже упоминалось, существуют четыре категории, в соответствии с принадлежностью к которым в NIS+ назначаются права доступа: владелец, группа владельца, все, никто. К первой категории может быть отнесен клиент, создавший данный объект или получивший его в собственность при помощи процедуры nischown. Как правило, для этой категории возможен любой из видов доступа - либо непосредственно, либо путем изменения соответствующих атрибутов, на что владелец также имеет право.
Один или несколько клиентов NIS+ могут составлять группу NIS+, на которую распространяются права доступа, присущие категории Group, по аналогии с правами доступа в файловой системе. Информация о группах NIS+ хранится в таблице NIS+ "Объекты". Любой клиент, прошедший аутентификацию NIS+, получает права категории World. Если же аутентификация не была проведена, клиент может получить права категории Nobody. Если же удостоверение поступило, но было неправильным, права Nobody на этого клиента не распространяются - ему автоматически запрещается получение сервиса.
Таблицы NIS+ имеют дополнительный уровень защиты, не предоставляемый для других типов объектов NIS+. Этот уровень построен на раздельном доступе к строкам и столбцам. Таким образом, для таблицы, в зависимости от требуемого клиентом сервиса, могут проверяться права на доступ к самой таблице, к данной строке и данному столбцу.
Защита RPC и NFS
NFS - мощный и удобный сервис, однако его использование сопряжено с угрозами безопасности информационной системы. По умолчанию NFS-сервер проводит аутентификацию клиента-машины, а не клиента-пользователя, что дает возможность несанкционированно получить привилегии суперпользователя (root). Для проведения аутентификации рекомендуется использовать гораздо более безопасный режим защищенных удаленных вызовов процедур, на основе которых строится защищенная сетевая файловая система (Secure NFS).
Как и в случае NIS+, каждый клиент-пользователь и клиент-машина имеют открытый и секретный ключи. При помощи программы keylogin проводится дополнительная аутентификация пользователя, расшифровывается его секретный ключ и передается программе keyserver, участвующей в процедуре RPC. Программа keyserver c секретным ключом пользователя ожидает запроса на RPC-сервис. С началом транзакции keyserver генерирует случайный сеансовый ключ, которым шифруется временной штамп машины-клиента. Затем находится открытый ключ сервера и вырабатывается DES-ключ, используемый для шифрации ключа сеанса. Далее формируется удостоверение клиента, включающее в себя сетевое имя, зашифрованный сеансовый ключ, допустимую разницу времени между клиентом и сервером и шифрованный временной штамп.
Когда сервер принимает запрос клиента, программа keyserver, установленная на машине-сервере, ищет открытый ключ клиента в своей базе данных и вырабатывает DES-ключ, используемый для расшифровки ключа сеанса. С помощью последнего расшифровывается временной штамп, полученный от клиента, и сравнивается с текущим временем сервера. Аутентификация считается удачной, если разность времени находится в пределах полученного "окна". Удостоверение клиента запоминается сервером, чтобы противостоять попыткам нелегальной аутентификации путем воспроизведения перехваченной информации.
В качестве свидетельства того, что аутентификация проведена успешно, да еще и "правильным" сервером, клиенту возвращаются его идентификационный номер в таблице сервера и временной штамп, уменьшенный на единицу и шифрованный сеансовым ключом. Последующие запросы клиент формирует, посылая серверу свой идентификационный номер и новые зашифрованные временные штампы. Таким образом, сеансовый ключ передается по сети один раз в шифрованном виде, причем расшифровать его можно, только зная пару соответствующих ключей клиента и сервера.
При использовании механизмов аутентификации Solaris 2.x необходимо учитывать следующее:
- если произошло нарушение безопасности сервера при работе в режиме защищенного RPC, все ключи сервера и клиентов из базы keyserver должны быть изменены;
- должна быть обеспечена физическая защищенность сервера;
- в момент загрузки бездисковых станций режим защищенного RPC не работает, следовательно, возникает угроза безопасности;
- нельзя применять программу keylogin при удаленном доступе на ненадежные машины, поскольку в этом случае туда посылается секретный ключ пользователя.
Kerberos-клиент
Современные информационные системы, как правило, разнородны. Достаточно популярной является комбинация UNIX-серверов с рабочими местами на базе ПК с NT или MS-DOS. Количество сервисов, требующихся для каждого пользователя, может быть велико, причем некоторые сервисы могут требоваться неявно. Это делает актуальной задачу выделения аутентификации в сетевой конфигурации в особый сервис, с назначением сервера аутентификации.
Стандартом де-факто такого сервера является Kerberos, который реализован сегодня практически на всех коммерческих системах аутентификации как сетевого уровня (CygnusKerberos, OpenVSecure), так и уровня приложений (Tuxedo).
Система Kerberos [1] представляет собой надежную третью сторону, которой доверяют все, владеющую секретными ключами обслуживаемых субъектов и помогающую им в попарной проверке подлинности. В этом качестве Kerberos-сервер должен быть физически защищен и иметь минимальное количество пользователей - желательно только системный администратор с локальной консоли. Работа в качестве Kerberos-клиента поддерживается в ОС Solaris. В частности, пользователь Solaris может генерировать удостоверение, передаваемое серверу аутентификации, используя команду kinit, и заканчивать сеанс при помощи команды kdestroy. Особенностью системы Solaris 2.x является возможность применить протокол Kerberos для файловых систем NFS. Это позволяет реализовать единый механизм аутентификации для всех видов сетевых сервисов.
Безопасность X-приложений
Одна из характерных черт современной операционной системы - возможность использования многооконного интерфейса для работы пользователей - для большинства UNIX-систем это стандарт X11. Поскольку X-сервер управляет такими ресурсами, как экран, клавиатура, "мышь", необходимо проводить разграничение доступа к этим ресурсам. При этом, с одной стороны, пользователь должен иметь возможность вызывать как локальные, так и удаленные X-приложения, в том числе выступая под различными пользовательскими именами, с другой стороны, несанкционированный доступ к этим ресурсам должен быть невозможен.
Для решения этой задачи применяются различные варианты авторизации. Наиболее простой вариант предполагает авторизацию по имени машины, запрашивающей сервис. Сопоставляя это имя со списком доступа, содержащимся в файле /etc/Xn.hosts и модифицируемым командой xhost, сервер разрешает или запрещает выполнение запроса клиента. Поскольку такой механизм авторизации заведомо недостаточен, - разрешая работать своим удаленным приложениям, вы неявно разрешаете работу приложений всех других пользователей этой машины - в X11 применяется механизм авторизации пользователей, называемый MIT-MAGIC-COOKIE. В этом случае, когда происходит инициализация сервера, генерируется последовательность байт, которая записывается в файл .Xauthority пользователя, открывающего сеанс на данном дисплее. После этого любой клиент получит разрешение на работу в данном сеансе только после предоставления этого кода серверу. Права доступа к файлу .Xauthority установлены в виде -rw-,что разрешает его чтение только владельцу.
В Solaris реализован дополнительный механизм авторизации, основанный на защищенных удаленных вызовах процедур с выработкой сеансового ключа аналогично ситуации с защищенным режимом для NFS. В файле .Xauthority содержится список управления доступом с указанием сетевых имен клиентов, которым разрешен доступ во время сеанса данного пользователя, а кроме собственно авторизации добавляется и аутентификация пользователя, что повышает надежность разделения доступа к этим ресурсам системы.
Доступность данных средствами Online Disksuite/Networker
Приведенные здесь инструменты ориентированы главным образом на предотвращение нарушений целостности или конфиденциальности данных. Третий компонент информационной безопасности - доступность - означает возможность получения необходимых пользователю данных или сервисов за разумное время, а это предполагает применение средств, отличных от описанных ранее.
Как правило, данные и программы хранятся на дисках - либо в рамках файловых систем, либо в виде неструктурированных разделов (raw partitions). Требование, состоящее в том, чтобы к этим информационным ресурсам можно было обращаться в любой момент, и чтобы такая операция занимала минимальное время, выглядит бесспорным. Однако, существует вероятность сбоя в работе дисков в результате неправильных действий пользователя, аппаратной ошибки или иных причин. Это заставляет использовать дополнительные средства для увеличения надежности системы и, соответственно, доступности данных. Одно из средств, увеличивающее надежность работы с дисковыми накопителями, - входящий в ОС Solaris продукт OnLine:DiskSuite.
Апробированным средством повышения производительности и надежности дисковых систем является использование избыточных массивов RAID [2] разных уровней. Для реализации технологии RAID продукт Online:DiskSuite создает псевдодрайвер диска и помещает его между пользовательскими приложениями и драйверами дисковых подсистем. Псевдодрайвер принимает пользовательские запросы на ввод/вывод и прозрачным для приложений образом переадресовывает их реальным устройствам. С точки зрения пользователя происходит увеличение скорости и надежности работы дисков без каких-либо аппаратных модификаций.
Online:DiskSuite позволяет также формировать "горячий резерв", который заменяет один из зеркалированных компонентов дисковой подсистемы в случае неисправности. Эта замена производится автоматически и не затрагивает процессов, обращающихся к данному устройству. Имеется возможность создать горячий резерв в качестве разделяемого ресурса, один для всех дисковых подсистем, управляемых Online:DiskSuite. Другая важная особенность дисковых подсистем на основе Online:Disksuite - возможность динамического изменения размеров файловой системы без остановки ее работы.
Увеличение надежности - одна из основных составляющих обеспечения доступности информационных ресурсов. Другой составляющей является систематическое резервное копирование программ и данных, с целью минимизации ущерба при возможных сбоях. Эта задача становится достаточно сложной в условиях работы с распределенными ресурсами в большой сети предприятия. Как правило, дополнительную трудность создает неоднородность сети, содержащей различные машины под управлением разных ОС. В состав Solaris входит программа NetWorker, позволяющая осуществлять централизованное создание резервных копий в рамках разнородной сети предприятия. Характерные особенностями этой программы:
- возможность работать с клиентами под управлением большинства имеющихся ОС;
- графический интерфейс;
- встроенное протоколирование с извещением о возникающих проблемах;
- оповещение локальных клиентов о проведении резервного копирования;
- открытый программный интерфейс;
- поддержка широкого спектра устройств резервного копирования;
- возможность делать копирование не всей системы, а лишь ее части в соответствии с набором критериев.
Заключение
С точки зрения защиты ресурсов самой операционной системы, Solaris предоставляет полный набор инструментов, решающих задачи. Отличительная особенность ОС Solaris - наличие встроенных средств контроля системных ресурсов (ASET) и средств системного аудита. Кроме этого, некоторые сетевые ресурсы, управляемые ОС Solaris, наряду с функционально полезными сервисами, также имеют встроенные средства защиты. В то же время при построении реальной информационной системы встроенных средств может оказаться недостаточно, вследствие, например, неоднородности конфигурации или использования небезопасных сервисов, особенно сетевых. Это - одна из главных причин, которая убеждает в необходимости средств усиления безопасности Solaris.
АО "Инфосистемы Джет" galaxy@jet.msk.su
Литература
[1]. Вьюкова Н. Сервер аутентификации Kerberos. - "Открытые системы", 1, 1996
[2]. Романчиков С. Современные RAID-контроллеры. - "Открытые системы", 2, 1996
