Болевые точки системы безопасности NetWare 4.x

Система безопасности NetWare 4.х далеко не безукоризненна, она имеет и откровенные изъяны. Однако следование определенной практике поможет увеличить степень защищенности этой сетевой операционной системы.

Архитектуру сетевой ОС можно классифицировать в соответствии с логическим или физическим компонентом, на уровне которого группируются сетевые ресурсы. В NetWare 3.х это сервер сети, в Windows NT - домен, а для NetWare 4.х - вся сеть как совокупность взаимодействующих элементов. В NetWare 3.х на каждом сервере была собственная база сетевых ресурсов BINDERY. Серверы этой сетевой ОС не были логически связаны друг с другом, и каждый находился под управлением своего супервизора (SUPERVISOR). Для работы с сетевыми ресурсами сервера пользователь сначала должен был зарегистрироваться на данном конкретном сервере, причем и имя, и пароль пользователя могли меняться от сервера к серверу.

В NetWare 4.х компания Novell значительно улучшила возможности администрирования, управления и использования сетевых ресурсов за счет внедрения службы каталогов (NDS). Все сетевые ресурсы здесь хранятся в распределенной базе NDS. Благодаря службе каталогов четвертая версия NetWare позволяет строить корпоративные сети с централизованным управлением. Теперь, чтобы воспользоваться сетевыми ресурсами, где бы они не находились (при наличии соответствующих прав), пользователю достаточно один раз зарегистрироваться в NDS. В NetWare 4.х вводится понятие администратора сети (Admin), отвечающего за централизованное управление всей сетью. При желании централизованное управление может быть заменено децентрализованным, однако это лишь подчеркивает достоинства NDS.

К сожалению, переход от серверной ориентации в NetWare 3.х к совершенно новой организационной модели сетевой архитектуры в NetWare 4.х не сопровождался адекватным изменением концепции безопасности сетевой ОС.

КОНСОЛЬ СЕРВЕРА

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

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

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

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

1. Чтобы корректно остановить какой-либо сервер, человек (оператор консоли или технический работник) должен иметь доступ к консоли сервера (возможно, через удаленную консоль). В NetWare 3.х положение спасала утилита FCONSOLE, посредством которой можно было останавливать сервер, не задействуя консоль сервера.

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

2. Такой злоумышленник без труда просмотрит структуру и содержание каталогов и томов сервера через MONITOR.NLM (опция File open/lock activity). При этом будут перечислены даже файлы с атрибутами "Hidden file" и "System file".

3. Используя модуль EDIT.NLM, злоумышленник может просмотреть любой небольшой текстовый файл, а если таковой файл не имеет атрибут "Read only", то изменить его не составит труда.

4. У злоумышленника появляется возможность запустить модуль удаленной консоли со своим паролем. При желании он может заблокировать основную консоль сервера через MONITOR.NLM.

5. Через удаленную консоль (RCONSOLE.EXE) посредством опции "Transfer Files To Server" злоумышленник может переписать с рабочей станции в любой каталог этого сервера какой угодно файл, в том числе и NLM-модуль. Если в целевом каталоге уже есть файл с аналогичным именем (даже с атрибутами "Delete inhibit", "Read only", "Rename inhibit"), то он заменяется на новый, правда, у нового файла всегда будет атрибут "Read/Write". Вместе с тем если у уже имеющегося файла был один из атрибутов "Hidden file" или "System file", то новый файл не будет записан на место старого, хотя его и можно переписать под другим именем.

6. Существует ряд общедоступных NLM-модулей для копирования файлов (при желании можно написать свой). Например, модуль COPY.NLM, поставляемый вместе с программой PowerChute Plus для ИБП фирмы APC, позволяет копировать файлы из одного каталога сервера в другой. Этот модуль отказывается копировать только тогда, когда в целевом каталоге уже есть аналогичные файлы с атрибутом "Read only". Посредством такой программы практически любой файл сервера может быть скопирован в тот каталог сервера, куда злоумышленнику разрешен доступ по сети. Смешно, но, чтобы скопировать на стример какой-либо файл утилитой SBACKUP, помимо доступа к консоли надо еще знать пароль администратора. Здесь же этого не требуется!

7. Запуск на сервере команды SECURE CONSOLE, которая выгружает DOS и позволяет запускать NLM-модули только из каталога SYS:SYSTEM, не спасает положения, поскольку с помощью п.п. 5 и 6 любой NLM-модуль можно переписать в системный каталог и запустить оттуда. У этой команды, правда, есть тот плюс, что она запрещает менять дату на сервере и обращаться к отладчику операционной системы.

8. Злоумышленник в большинстве случаев может выгрузить уже функционирующие NLM-модули и, самое неприятное, запустить любые NLM-модули на сервере даже в режиме ядра сетевой ОС (кольцо 0 центрального процессора), причем специально созданные NLM-модули могут разрушить целостность, надежность и защищенность системы.

Это особенно критично, если сервер, к консоли которого получил доступ злоумышленник, содержит основную копию (master replica) или копию чтения/записи (read/write replica) раздела NDS (NDS partition), а также если сервер участвует в синхронизации времени в сети в качестве сервера времени. Это может привести к порче и даже разрушению NDS.
Подводя итоги можно утверждать, что злоумышленник, получивший доступ к консоли, в общем случае в состоянии:

· подменить системные NLM-модули;

· установить и запустить любые NLM-модули (в том числе с вирусами, сбойные или нарушающие безопасность системы);

· выгрузить уже запущенные NLM-модули;

· просмотреть и изменить текстовые файлы средствами сетевой ОС;

· скопировать любые файлы, в том числе и с конфиденциальной информацией;

· изменить конфигурацию сервера и, вообще, сделать сервер неработоспособным.

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

Теоретически правила NetWare 4.х соответствуют уровню безопасности C2, но в реальной жизни все несколько сложнее. Для того чтобы корректно остановить сервер или запустить сервис BOOTP, человек должен обладать правами администратора сервера! А как же быть с принципами "Оранжевой книги" по минимизации привилегий и разграничению полномочий?

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

1. Основные средства управления сервером сосредоточены на консоли, и их нельзя задействовать через административные утилиты типа NETADMIN и NWadmin.

2. Лицо, имеющее доступ к консоли, автоматически получает все права и привилегии администратора (оператора) сервера (на самом деле даже больше).

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

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

Надежное администрирование в сетевой ОС предполагает выделение трех логических ролей: администратора сети, администратора сервера и администратора аудита. Эти обязаности может выполнять один человек, но не одновременно. В NetWare 4.х функция администратора сети состоит в управлении NDS. Месторасположение NDS и журналов аудита на файловом сервере напрямую не связано с файловыми системами сервера. Доступ к ним на уровне файловых операций невозможен.

Что касается администратора аудита, то его функции в NetWare 4.х тщательно проработаны. То же самое относится и к фунциям администрирования сети (NDS), хотя критически важная функция управления временем в сети, к сожалению, переложена на администратора сервера. Поскольку NDS представляет распределенную и тиражируюмую базу, то некорректное изменение времени на сервере (для сервера времени) может привести к искажению NDS.

Статус администратора сервера в NetWare 4.х оказался логически не согласованным и не четким. В NetWare 4.х администратор сервера ассоциирован с оператором консоли. Однако в противовес администратору аудита и администратору сети он не имеет представления в NDS. Вернее, администратор сети через NDS может определить оператора консоли для сервера (в качестве свойства сервера как объекта NDS). Но это назначение не несет никакой функциональной нагрузки. Этот пользователь не получает никаких новых прав или возможностей. Чтобы управлять сервером NetWare 4.х ему надо иметь доступ к консоли, не зависимо от того, объявлен он оператором консоли или нет. В NetWare 3.х определение пользователя в базе Bindery как оператора консоли позволяло ему управлять сервером через утилиту FCONSOLE (правда, эти функции были ограничены по сравнению с доступом через консоль). В то же время все действия лица, получившего доступ к консоли сервера NetWare, отождествляются с действиями самого сервера. Если, например, через консоль создаются файлы, то их владельцем считается сам сервер.

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

Тем не менее с помощью ряда технических и организационных мер можно значительно снизить возможность несанкционированного вторжения через консоль.

1. Необходимо резко ограничить круг лиц, имеющих доступ к консоли. Конечно, лучше всего размещать серверы в специальных комнатах, недоступных для посторонних, однако в реальной жизни это не всегда возможно. Поэтому лучше закрыть доступ к консоли на аппаратном уровне с помощью пароля или замка на сервере. Можно также установить пароль на консоль через MONITOR.NLM, хотя такой вариант сам по себе недостаточно надежный. Использование удаленной консоли снижает безопасность системы, поэтому ей лучше не пользоваться. Доступ к консоли должны иметь только администратор сети и администратор данного подразделения, тогда никто, кроме них, не сможет изменять настройку, устанавливать, запускать и удалять программы на сервере.

2. Для технического персонала, ответственного за включение/выключение сервера, предпочтительнее использовать продукты третьих фирм. Так установка на сервере источника бесперебойного питания Smart-UPS фирмы APC позволяет не только обеспечивать сервер электропитанием при неполадках с электричеством. Программа PowerChute Plus для Smart-UPS предоставляет возможность корректно останавливать сервер и отключать электропитание с рабочей станции сети. Более того, она позволяет программировать включение и выключение сервера (и электропитание) по расписанию. Администратору необходимо только предоставить права на чтение каталога с PowerChute Plus техническому персоналу и сообщить пароль для запуска этой программы. Однако технический персонал не сможет выполнять какие-либо другие административные обязанности.

3. Для наименее защищенных серверов рекомендуется запускать систему аудита, а важнейшим системным файлам присваивать атрибуты "Hidden file" и "System file". На такие серверы не следует устанавливать основные копии или копии чтения/записи разделов NDS и, кроме того, лучше не использовать их в качестве серверов времени.

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

КЛИЕНТЫ СЕТИ

Сейчас стало чрезвычайно модно говорить о невысокой безопасности сетей TCP/IP вообще и Internet в частности. При этом многие считают протоколы NetWare чуть ли не образцами в смысле безопасности. На самом деле это не совсем так. Как известно, сетевой адрес узла в сети IPX/SPX имеет вид <адрес сети>:<адрес хоста>, где в качестве <адреса хоста> выступает MAC-адрес сетевой платы. Вместе с тем многие платы допускают изменение данного адреса программным способом. Для клиентов NetWare это достигается настройкой параметра "NODE ADDRESS" в разделе "Link Driver" конфигурационного файла NET.CFG. После такой операции клиент получает совершенно другой <адрес хоста>. Дело осложняется в сети, где широко используются коммутирующие концентраторы (сейчас это становится повсеместным), поскольку там задействовано очень мало <адресов сетей>, а порой и вовсе один адрес (если не используется глобальная сеть). У злоумышленника появляются неплохие шансы установить на своем ПК тот же адрес, что и у административной машины.

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

Было бы неплохо, если компания Novell в своих клиентских программах отказалась бы от поддержки перепрограммирования MAC-адресов. От "профессионалов" (взлома) это не спасет, но оградит от деятельности "любителей".

ГЛАВНЫЙ АДМИНИСТРАТОР СЕТИ

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

По умолчанию администратор в NDS имеет контекст CN=Admin.O=<организация>, где <организация> - имя организации. Поскольку имя, место в контексте и права администратора известны всем, то попытки несанкционированного вторжения будут предприниматься в первую очередь именно здесь. К тому же по умолчанию NetWare даже не фиксирует неудачные попытки проникновения в систему с правами администратора. Поэтому имеет смысл создать специальный контейнер в рамках контекста организации (Organization) и поместить туда бюджет особого пользователя. Данному пользователю нужно присвоить все полномочия главного администратора, после чего объект CN=Admin.O=<организация> следует удалить. К сожалению, по непонятной причине в NetWare 4.х больше не запрашивается пароль пользователя, если неправильно набрано имя. Простым перебором распространенных имен можно установить имя, причем эти попытки даже не будут фиксироваться. Поэтому администратору следует дать особенное имя. Используя возможности фильтра наследуемых прав (Inherited Rights Filter), необходимо также запретить обычным пользователям просматривать содержание созданного контейнера.

Для защиты "от дураков" рекомендуется ограничить список рабочих станций сети, с которых администратор может входить в сеть (как уже отмечалось, данное ограничение во многих случаях легко преодолевается). Пароль администратора следует периодически менять. Это должен быть нетривиальный пароль, состоящий не менее чем из 6 символов. В контейнере NDS, где расположен бюджет администратора, необходимо задействовать систему обнаружения несанкционированного доступа (Intruder Detection). Опять же, к сожалению, в NetWare 4.х не существует средств, при входе в сеть автоматически сообщающих о количестве неудачных попыток проникновения в систему, поэтому администратор должен самостоятельно, через утилиты NETADMIN или NWadmin, периодически отслеживать эту информацию.

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

4.X = 3.X + ?

Изменения в системе безопасности NetWare 4.x по сравнению с NetWare 3.x

1. Аутентификация (идентификация) пользователя. Аутентификация пользователя в NetWare 4.х происходит с использованием алгоритма RSA (шифрование с открытым ключом). Ни пароль пользователя, ни закрытый ключ здесь никогда не передаются по сети. Однако в NetWare 4.x (в отличие от NetWare 3.х, UNIX, Windows NT) не запрашивается пароль для пользователя, имени которого нет в базе системы.

2. Подпись пакетов NCP (NetWare Core Protocol). В NetWare 4.х и 3.12 для повышения безопасности введена возможность подписи пакетов NCP. Существует несколько вариантов реализации такого механизма как на рабочей станции, так и на сервере: обязательность подписи, подпись по запросу, отсутствие подписи. Однако пакеты SPX (по этому протоколу работает удаленная консоль) не подписываются.

3. Система аудита. В NetWare 4.х имеется полноценная система аудита (AUDIT), позволяющая осуществлять мониторинг системы безопасности и использования сетевых ресурсов. Система аудита управляется администратором аудита и действует независимо от системного администратора сети и других пользователей. Система аудита в NetWare 4.х позволяет отслеживать события, связанные с изменением состояния, во-первых, файлов и каталогов, во-вторых, сервера, в-третьих, NDS.

4. Права доступа к объектам. В NetWare 3.х имелись весьма ограниченные возможности управления правами доступа к объектам BINDERY. В NetWare 4.х для работы со службой каталогов были добавлены права доступа к объектам NDS (NDS object rights) и права доступа к свойствам объектов NDS (NDS property rights). По сравнению с NetWare 3.х права доступа к файлам и каталогам в NetWare 4.х не претерпели особых изменений.

5. Наследование прав. В NetWare 3.х имелся механизм наследования прав на уровне каталогов, управляемый маской наследуемых прав (Inherited Rights Mask - IRM). В NetWare 4.х механизм наследования распространен на NDS. Фильтр наследуемых прав (Inherited Rights Filter - IRF) управляет этим механизмом вниз по структуре NDS и по структуре каталогов файлов.

6. Управление сервером. В сравнении с NetWare 3.х принципы управления сервером в NetWare 4.х не претерпели каких-либо серьезных изменений. Однако в NetWare 4.х отсутствует аналог утилиты FCONSOLE, позволяющей в ранних версиях NetWare осуществлять некоторые административные действия по управлению сервером с рабочей станции сети.

7. Системная архитектура сетевой ОС. В NetWare 3.х все NLM-модули запускались в режиме ядра системы (кольцо 0 центрального процессора). В NetWare 4.х добавлена возможность запускать некоторые NLM в кольце 3 центрального процессора, однако в каком режиме запускать программу определяет не она сама, а оператор сервера. Поэтому данную характеристику архитектуры NetWare 4.х лишь условно можно отнести к системе безопасности.

УДАЛЕННЫЕ ПОЛЬЗОВАТЕЛИ МОГУТ БЫТЬ СПОКОЙНЫ

Защита при удаленном доступе к локальной сети

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

В системе с удаленными узлами коммутируемая линия становится продолжением локальной сети, и удаленная машина работает в сети как равноправный клиент. На рынке имеется большой выбор программных и программно-аппаратных серверов удаленных узлов. Среди программных решений можно выделить встроенные в Windows NT Server и OS/2 Warp Server серверы удаленных узлов, а также продукт NetWare Connect фирмы Novell. Среди программно-аппаратных решений наиболее известны такие продукты, как AccessBuilder фирмы 3Com и LanRover/E фирмы Shiva. Они играют роль шлюза между удаленными узлами и локальной сетью. Данные решения отличаются возможностями защиты, однако есть несколько общих подходов.

Практически все системы позволяют организовывать обратный вызов по фиксированному или блуждающему телефонному номеру: сначала пользователь вызывает сервер удаленного доступа, набирает имя и пароль, после чего соединение разрывается и сервер сам вызывает клиента. При фиксированном обратном вызове телефонный номер клиента занесен в базу сервера. При блуждающем обратном вызове клиент сам всякий раз указывает свой телефонный номер. Это удобно, если клиент не имеет постоянного телефонного номера (например находится в командировке). С точки зрения обеспечения безопасности, вариант с фиксированным вызовом более предпочтителен. Однако подключение с блуждающим обратным вызовом или без обратного вызова тоже можно сделать безопасным, используя, например, аппаратные ключи InfoKey и InfoCard фирмы LeeMah DataCom Security. Большинство серверов удаленных узлов обеспечивают двухступенчатый доступ к сетевым ресурсам: сначала к самому серверу удаленных узлов и лишь затем к локальной сети, что значительно увеличивает степень защищенности сети. Для защиты сервера удаленных узлов от несанкционированного доступа обычно используют протоколы идентификации пользователя PAP (Password Authentication Protocol), CHAP (Challenge Handshake Authentication Protocol), SPAP (Secure Password Authentication Protocol), Kerberos. Некоторые серверы удаленных узлов (например, в Windows NT Server) позволяют шифровать не только пароли, но и данные. Абсолютное большинство серверов удаленных узлов позволяют вести журналы регистрации подключений и поддерживают опцию ограничения времени сеанса связи.

При удаленном управлении клиент получает доступ к экрану хост-машины. Хост-машина принимает сигналы от мыши и клавиатуры клиента, а взамен посылает изображение (обновления изображения). Через хост-машину клиент может получить и доступ к локальной сети. Наиболее известные программы удаленного управления - Norton pcAnywhere фирмы Symantec, Carbon Copy for Windows фирмы Microcom и др. Для защиты от несанкционированного доступа программы удаленного управления предоставляют следующие возможности:

· обратный вызов (фиксированный или блуждающий);

· шифрование паролей;

· регистрацию событий;

· ограничение доступа к дискам хост-машины.