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

С.Д. Рябко
Генеральный директор ЗАО "С-Терра СиЭсПи", к.ф.-м.н.

Удаленный доступ: в чем проблемы безопасности?

В современном мире стремительно растет число мобильных пользователей информационных систем и "информационных надомников". Эта тенденция нашла отражение даже в лингвистике - в обиход технического английского языка прочно вошли неологизмы telecommuter и teleworker.

При этом на сегодня стали массово доступными коммуникационные ресурсы удаленного доступа. Если 5-10 лет назад удаленный пользователь мог воспользоваться только модемом на коммутируемой линии (который остается распространенным и недорогим инструментом), то сегодня практически повсеместно распространены GPRS, xDSL и быстро растет зона покрытия сервисов мобильной телефонии 3G, сочетающих высокую скорость передачи данных, надежность канала и очень разумные цены.

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

В чем же специфика удаленного доступа с точки зрения информационной безопасности? Чем задача защиты удаленного пользователя отличается от задачи защиты "внутреннего" пользователя корпоративной сети?

Удаленность рабочего места внешнего пользователя порождает, в сравнении с локальным офисным рабочим местом, три дополнительных фактора угроз:

1. Мобильный пользователь находится вне зоны прямого физического контроля организации. Требуется доказательство того, что к корпоративному ресурсу подключается именно "свой" пользователь, а не злоумышленник, "прикинувшийся" своим.
2. Данные удаленного пользователя распространяются по каналам, которые находятся вне зоны контроля организации. Эти данные подвержены перехвату, несанкционированной модификации, "подмешиванию" постороннего трафика.
3. Для рабочего места организация не может обеспечить физическую безопасность. Его не может защитить охрана офиса, оно может быть похищено. Оно может не соответствовать требованиям организации по конфигурации.

Возникает вопрос - в какой мере можно нейтрализовать влияние этих негативных факторов?

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

Удаленный доступ: выбор базовой технологии защиты

Сегодня в области защиты удаленного доступа довольно жестко конкурируют технологии безопасности сетевого (IPsec) и транспортного (SSL/TLS) уровня.

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

1. IPsec VPN;
2. "классический" сценарий применения защиты транспортного уровня на базе протоколов SSL или TLS;
3. SSL (TLS) VPN.

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

Что же касается коммуникационного протокола - решение IPsec одновременно и более гибко, и более сложно как по реализации, так и в эксплуатации. В архитектуре IPsec (рис. 1, а): трафик приложений передается на сетевой уровень в виде пакетов, пакеты перехватываются, шифруются и подписываются. Специальный протокол, Internet Key Exchange, IKE, заботится об управлении ключами и согласовании политик безопасности.

Консалтинговая компания The Burton group в одном из аналитических отчетов утверждала, что VPN-решения на базе протокола IPsec для систем с более высокими требованиями по безопасности предпочтительны в сравнении с SSL/TLS VPN.

Что касается "классической" схемы применения протоколов SSL/TLS (рис. 1, б), то это вовсе не VPN.

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

Классическое SSL/TLS-решение не соответствует этому определению. Оно обеспечивает целостность и конфиденциальность одного транспортного соединения (трафик приложения 3 на рис. 1, б). Другие же приложения (1 и 2 на рис. 1, б) передают открытый трафик, и доступ к их "незашифрованным" портам никто не контролирует. Такая незамкнутость контура защиты компьютера в SSL/TLS меня всегда очень смущала...

Но у этого решения есть своя, практически неконкурентная, "экологическая ниша". В системах защиты массового (не корпоративного) удаленного доступа, где мы не можем установить каждому пользователю "наш" VPN-клиент, альтернативы Web-браузеру, поддерживающему SSL- или TLS-сое-динение, просто нет. Поэтому электронная коммерция, системы доступа частных лиц к банковским ресурсам и прочие системы с массовым и неподконтрольным парком пользователей построены по схеме Web-браузер - защищенное SSL/TLS соединение - портал.

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

Технологии SSL/TLS VPN (рис. 1, в) получили распространение относительно недавно, около 5 лет назад. Мотивом для создания VPN-продуктов на основе транспортных протоколов была идея создать более простое и дешевое в эксплуатации VPN-решение. Однако здесь, как это часто случается в сюжете "хотели как лучше", возникли нюансы. Решение "расползлось" в две сугубо различные архитектуры: "псевдо-VPN" и "честный VPN", которые существенно различаются по своим свойствам.

Архитектура "псевдо-VPN" показана на рис. 2.

В качестве VPN-клиента в "псевдо-VPN" выступает простой Web-браузер. Шлюз безопасности на внешнем периметре корпоративной сети представляет собой защищенный Web-сервер, который "показывает" VPN-клиентам ресурсы защищаемой им сети в виде Web-ресурсов. При этом защищаемые ресурсы вовсе не обязательно должны представлять собой Web-странички. Это могут быть файловые системы, даже чат, голос и видео. Чтобы сделать эти ресурсы доступными через браузер, "позади" Web-сервера располагается прокси-сервер, транслирующий данные ресурсы в HTTP и обратно.

В чем прелесть такого решения? В том, что для построения VPN с клиентской стороны вовсе ничего не нужно. Браузер есть на любой машине. SSL или TLS есть почти в каждом браузере. Сертификат (ключ) не обязателен: и SSL и TLS "умеют" выработать временный сеансовый ключ "на лету". Аутентифицировать пользователя можно позднее, под защитой сеансового ключа, например, при помощи пароля.

В чем основные недостатки? Их два.

• Первый: это все-таки не VPN. По цитированному выше определению, здесь пользователи не могут "взаимодействовать между собой, как если бы они находились в единой закрытой сети". Они получают только функциональность доступа к избранным ресурсам защищенной сети. Причем, состав "избранных ресурсов" ограничен возможностями прокси-серверов в составе VPN-шлюза. Те ресурсы, доступ к которым "отпроксировать" не удастся, будут навечно недоступны.
• Второй: клиентский парк также может быть защищен лишь отчасти. Приложения, в которых клиентская часть представляет собой не Web-браузер, а что-то другое, - беззащитны. И деятельность пользователей за пределами событий доступа к Web-VPN-шлюзу полностью неподконтрольна.

Теперь становится яснее озабоченность аналитиков из The Burton group, рекомендовавших для защиты критичных ресурсов IPsec - он не делает исключений.

Осознавая эти недостатки, индустрия SSL/TLS VPN пошла на усложнение архитектуры, предлагая "честный" VPN. Наиболее ярким примером такого решения является прекрасно проработанный и описанный в нескольких книгах проект OpenVPN (http://openvpn.net). Архитектуру этого (и подобных) решений можно понять из диаграммы на рис. 1, в. Трафик приложений (всех или части) упаковывается в открытый транспортный протокол, потом в IP-пакеты, которые перехватываются и повторно инкапсулируются в протокол транспортного уровня с применением средств защиты SSL или TLS. Что мы получаем в итоге? Полнофункциональный "честный" VPN, очень похожий на решение IPsec. Однако платой за такое решение является необходимость установки VPN-клиента. Никуда не денешься - браузер не умеет перехватывать и упаковывать в транспортный протокол IP-пакеты...

Каковы преимущества "честного" SSL/TLS VPN? Разработчики продуктов в этой технологии говорят, что он "намного легче" IPsec. Я бы сказал "несколько легче" - и то с натяжкой:

• Как и в IPsec, на машину удаленного пользователя нужно установить VPN-клиент.
• По уму, надо бы раздать пользователям сертификаты.
• Как и в IPsec, нужно сконфигурировать политику безопасности...

Собственно, установка и конфигурирование VPN-клиента считается главной трудностью внедрения IPsec в массовом парке удаленных пользователей. Где же "облегчение"?

Некоторое облегчение есть в простоте протокола и политики безопасности. Некоторое облегчение есть в цене: SSL/TLS VPN-продукты бывают несколько дешевле. Но, с другой стороны, - технические возможности этих продуктов более узки. Продукты разных производителей (в силу нестандартности инкапсуляции пакетов в транспортный протокол) практически несовместимы, чего не скажешь об IPsec-продуктах...

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

1. На порталах массового доступа - "чистый" SSL/TLS, что не есть, по сути, VPN.
2. Там, где требования безопасности невысоки, а пользователей много и они малоквалифицированны, - хорошо использовать "псевдо-VPN" на основе SSL или TLS.
3. Когда речь идет о строгом корпоративном решении и о доступе к критичным ресурсам - однозначно следует применять только "честную" VPN-архитектуру. IPsec или SSL/TLS VPN? Тут - выбор на любителя.

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

Удаленный доступ: практические вопросы дизайна архитектуры VPN

Как учесть риски "человеческого фактора"?

Как-то в фундаментальной работе "Cisco SAFE: IPsec VPNs in depth" меня поразила одна фраза: "Может ли ваша организация доверять VPN в той же мере, что и выделенному WAN-каналу? <...> Cisco и большинство заказчиков исходят из того, что VPN-канал заслуживает несколько меньшего доверия". Это как же? Шифрование на ключах 128 бит и ЭЦП авторы считают защитой, которая менее надежна, чем открытый канал за пределами контролируемой зоны организации?! Звучит, мягко говоря, странно. Но, внимательно перечитав текст, я понял, чего недоставало в этой фразе: "Cisco и большинство заказчиков исходят из того, что VPN-канал [эксплуатируемый реальными, немотивированными, возможно - неквалифицированными, в какой-то части - прямо злоумышленными пользователями] заслуживает несколько меньшего доверия".

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

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

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

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

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

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

Пустите пользователя "внутрь ЛВС"

Как уже говорилось выше, "честное" VPN-решение позволяет "распространить" нашу локальную сеть в удаленную зону. Или, что эквивалентно, виртуально "усадить" удаленного пользователя в офисную локальную сеть. Из этой функциональности вытекают два удобства:

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

Последняя возможность заслуживает краткого пояснения. Дело в том, что все VPN-протоколы обеспечивают строгую взаимную аутентификацию партнеров по взаимодействию. Мы можем практически с юридически значимой достоверностью утверждать, что данный IPsec-пакет принадлежит, скажем, Ивану Ивановичу Иванову. Когда же IPsec-пакет прибывает на шлюз безопасности и передается в локальную сеть предприятия как открытый IP-пакет - аутентифи-кационная информация теряется: в IP-заголовке нет полей, несущих информацию об издателе пакета. Обидно! Однако связать аутентификацион-ную информацию IPsec с открытым IP-пакетом все-таки можно. Это остроумное решение первой внедрила, по моим сведениям, компания Cisco Systems в конце 1990-х. Реализуется оно так.

1. Внутри IPsec-туннеля VPN-клиент удаленного пользователя формирует виртуальный сетевой интерфейс, которому присваивается заданный IP-адрес. Этот IP-адрес относится к частному (внутреннему) адресному пространству корпоративной сети (рис. 3). Тем самым удаленный пользователь как бы становится внутренним пользователем корпоративной сети.
2. IP-адрес, выдаваемый данному удаленному пользователю, может ассоциироваться лично с этим пользователем или (так делают чаще) некоторый пул адресов ассоциируется группой пользователей, обладающих равными правами доступа. Тем самым мы как бы усаживаем всех пользователей с одинаковыми правами доступа в один сегмент локальной сети нашего офиса.
3. Далее внутри корпоративной ЛВС как для локальных, так и для удаленных пользователей реализуется единая политика безопасности. Инструментами выступают традиционные сетевые средства контроля доступа - межсетевые экраны, коммутаторы, VLAN.

Эта общая схема может реализовы-ваться в продуктах разных производителей по-разному. "Пригласить" удаленного пользователя внутрь корпоративной VPN можно при помощи:

• туннелирования второго (канального) уровня, например, упаковывая Ethernet-фреймы пользователя в протокол L2TP и затем защищая L2TP при помощи IPsec;
• построения IPsec-туннеля от удаленного пользователя в корпоративную сеть и далее - конфигурирования его IP-стека при помощи протокола DHCP;
• использования VPN-протоколов для конфигурирования удаленных пользователей. Например, расширение протокола управления ключами IKE, IKE-CFG является одним из наиболее удобных и легких в реализации решений.

Иерархические конструкции сетевой защиты

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

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

Интересно, что политика безопасности VPN хорошо настраивается на построение таких эшелонированных систем.

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

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

Однако при удаленном доступе пользователей все становится не так просто. Рассмотрим удаленного пользователя, который должен получить доступ из открытой сети к ресурсам наиболее конфиденциального внутреннего периметра. В этом случае VPN-клиент удаленного пользователя должен установить вложенные VPN-туннели последовательно со шлюзом внешнего контура ("ОИ"), шлюзом конфиденциального контура ("К") и шлюзом строго конфиденциального контура ("СК", рис. 5, б). Хорошее VPN-решение должно обеспечивать возможность построения такой асимметричной системы вложенных VPN-туннелей.

Однако дизайн "вложенных VPN", показанный на рис. 5, часто вызывает ряд вопросов:

• насколько увеличивается защищенность самого внутреннего (строго конфиденциального) периметра оттого, что трафик его трижды шифрован?
• нужно ли нам нести расходы на VPN на каждом контуре защиты, включающие:
• цену VPN-шлюзов;
• цену избыточного трафика (каждый контур защиты накладывает на IP-пакет дополнительные заголовки, увеличивая тем самым объем непродуктивного служебного трафика);
• задержку на промежуточные этапы обработки и, возможно, ограничение полосы пропускания системы?

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

Это означает, что во вложенной VPN с рис. 5 разумно обеспечить прежде всего шифрование трафика на контуре обработки информации с грифом "строго конфиденциально" на шлюзе "СК".

Но что даст нам в плане защиты второе шифрование "строго конфиденциального" трафика на периметре обработки конфиденциальной информации (шлюз "К")? Теоретически, дополнительное шифрование обеспечивает дополнительную защиту. Практически - трафик уже шифрован по ГОСТ 28147 на ключе 256 бит. Повторное шифрование увеличит нам эффективную длину ключа ориентировочно до 512 бит. Но зачем нам это нужно, если шифрование только на ключе 256 бит уже обеспечивает нам более чем достаточную стойкость защиты контура "строго конфиденциально"?

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

"Свобода доступа" удаленного пользователя

Следующим по важности вопросом дизайна сети удаленного доступа является проблема доступа пользователя в Интернет. В уже цитированной работе Cisco рассматривается архитектура split tunnel, в которой пользователь может получать доступ одновременно в корпоративную сеть и в Интернет.

Опасность такой конструкции в том, что пользователь, нахватав в Интернете вирусов и прочей грязи типа spyware, может стать агентом транзитной атаки на корпоративную сеть (рис. 6).

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

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

Рекомендуется на сегменте удаленного доступа применять только изолирующую политику VPN, в соответствии с которой удаленный пользователь может получить доступ только в корпоративную сеть и никуда более. На первый взгляд, такой подход вызывает ряд вопросов. Первый из них: как быть, если удаленному пользователю требуется доступ в Интернет?

Ответ прост: пропустите ваших удаленных пользователей по защищенному каналу в корпоративную сеть, а затем выпустите удаленных пользователей в Интернет "на общих основаниях", применяя те же меры защиты, что и для рядовых пользователей локальной вычислительной сети офиса (рис. 7).

Такое решение предоставляет два важнейших преимущества:

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

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

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

Тут ответ так же прост: надежность регулируема по потребностям заказчика. Во-первых, VPN-концентратор удаленного доступа легко резервируется, причем - по схеме N + 1 с выравниванием нагрузки. Во-вторых, если ваша сеть регионально распределена, то никто не мешает вам установить концентраторы доступа в 2-3 городах. Поскольку цена за трафик внутри страны практически не зависит от того, подключены вы к шлюзу безопасности в Москве, Санкт-Петербурге или во Владивостоке - дайте пользователям возможность входить в корпоративную сеть через несколько региональных концентраторов доступа. И вы практически без дополнительных затрат получите надежность на уровне катастрофоустойчивости.

Аутентификация

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

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

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

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

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

Управление конфигурациями

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

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

Такая технология появилась около двух лет назад. Компания Cisco Systems предложила идеологию Network Admission Control (NAC). Суть NAC сводится к тому, чтобы при допуске в сеть через удаленное устройство, у него проверялось соответствие конфигурации требованиям корпоративной политики безопасности. Например, от удаленного пользователя может требоваться наличие определенного набора установленных средств защиты, своевременного обновления антивирусных баз данных, активности, или, наоборот, запрета определенных приложений. В случае, если конфигурация рабочего места удаленного пользователя не соответствует требованиям корпоративной политики, он не получает доступа в корпоративную сеть или получает доступ только в карантинную зону, где он сможет "привести себя в порядок": например, загрузить требуемые обновления, провести антивирусное сканирование и т.п.

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

Резюме

Объемы этой статьи не позволяет разобрать детали сценариев построения корпоративных VPN удаленного доступа. Поэтому в заключение разумно перечислить основные принципы, следуя которым вы не "промахнетесь" при разработке конкретных систем:

1. Не доверяйте пользователю. Не предоставляйте ему возможности изменять политику безопасности и конфигурацию рабочего места.
2. Применяйте надежные методы аутентификации. Предпочтение отдавайте системам с двухфакторной аутентификацией с защищенным от пользователя, секретом. Система аутентификации не должна также требовать от пользователя запоминания чего-то более сложного, чем короткий PIN-код. Секрет, хранимый в памяти пользователя, не должен быть базой его аутентификации. В противном случае пользователь вольно или невольно неизбежно скомпрометирует этот секрет.
3. Применяйте изолирующую политику VPN. Не допускайте прямого контакта внутренних ресурсов корпоративной сети (к которым следует относить и ресурсы рабочего места удаленного пользователя) с недоверенной средой типа ресурсов Интернет.
4. Аутентифицировав и надежно изолировав пользователя от недоверенных ресурсов, вводите его в инфраструктуру локальной сети и применяйте к нему такие же типовые меры защиты, как и к любому локальному офисному пользователю.
5. В числе мер информационной безопасности, применяемых как к локальным, так и к удаленным пользователям, особое внимание уделяйте контролю над происходящим в сети: событийному протоколированию, аудиту, мониторингу событий безопасности, выявлению и анализу аномальных активностей. Для удаленных пользователей эти меры контроля целесообразно повысить по сравнению с локальными офисными рабочими местами.

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

Литература

1. RFC 4026, L. Andersson, T. Madsen, Acreo AB, " Provider Provisioned Virtual Private Network (VPN) Terminology ", March 2005.
2. SAFE VPN IPSec Virtual Private Networks in Depth. Cisco Systems, Inc., 2004.
3. Dukes, D. and R. Pereira, "The ISAKMP Configuration Method", draftietf-ipsec-isakmp-cfg-03.txt.

1 Стр. 10. Сегодня эта книга отсутствует на сайте Cisco. Предполагаю – по причине обновления стандартов IPsec. Книга была написана для архитектуры IPsec RFC 2401 и не была обновлена для новой архитектуры RFC 4301. Жаль, работа представляла интересное руководство по дизайну VPN, которое не стареет с выходом новой версии протокола.

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

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

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

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

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

2. Необходимо установить программу работы с удаленной сетью - Dial-Up Networking Server, которая входит в программный пакет Microsoft Plus!.

3. Войти в программу Удаленный доступ к сети (Пуск | Программы | Стандартные | Удаленный доступ к сети).

4. В меню Соединения выбрать команду Сервер удаленного доступа.

5. Выбрать переключатель Allow caller access, после чего сервер будет отвечать на входящие звонки и предоставлять доступ к ресурсам сети удаленным пользователям. Эти ресурсы будут предоставляться так, как будто компьютеры соединены в локальную сеть. При необходимости можно задать пароль для входа в сеть.

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

1. Необходимо выбрать в меню Соединения команду Новое соединение, где

следует указать имя соединения, номер телефона сервера и пароль для входа в сеть.

2. После этого в окне Удаленный доступ к сети появится новый значок для соединения с сервером.

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

4. Затем следует включить модем и нажать кнопку Установить связь. После этого модем дозвонится до сервера, что позволит войти в удаленную сеть.

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

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

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Подобные документы

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

курсовая работа , добавлен 11.01.2013


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

курсовая работа , добавлен 17.12.2011


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

реферат , добавлен 08.01.2011


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

контрольная работа , добавлен 12.07.2014


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

курсовая работа , добавлен 25.04.2014


Разработка проводной локальной сети и удаленного доступа к данной сети с использованием беспроводной сети (Wi-Fi), их соединение между собой. Расчет времени двойного оборота сигнала сети (PDV). Настройка рабочей станции, удаленного доступа, сервера.

курсовая работа , добавлен 10.11.2010


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

курсовая работа , добавлен 29.01.2011

Telnet - это одна из самых старых информационных технологий Internet. Она входит в число стандартов, которых насчитывается три десятка на полторы тысячи рекомендуемых официальных материалов сети, называемых RFC (Request For Comments).

Под telnet понимают триаду, состоящую из:

• telnet-интерфейса пользователя;
• telnetd-процесса;
• TELNET-протокола.

Эта триада обеспечивает описание и реализацию сетевого терминала для доступа к ресурсам удаленного компьютера.

В настоящее время существует достаточно большое количество программ - от Kermit до различного рода BBS (Belluten Board System), которые позволяют работать в режиме удаленного терминала, но ни одна из них не может сравниться с telnet по степени проработанности деталей и концепции реализации. Для того, чтобы оценить это, знакомство с telnet стоит начать с протокола.

3.3.1. Протокол Telnet

Telnet как протокол описан в RFC-854 (май, 1983 год). Его авторы J.Postel и J.Reynolds во введении к документу определили назначение telnet так:

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

Telnet строится как протокол приложения над транспортным протоколом TCP. В основу telnet положены три фундаментальные идеи:

• концепция сетевого виртуального терминала (Network Virtual Terminal) или NVT;
• принцип договорных опций (согласование параметров взаимодействия);
• симметрия связи "терминал-процесс".

При установке telnet-соединения программа, работающая с реальным терминальным устройством, и процесс обслуживания этой программы используют для обмена информацией спецификацию представления правил функционирования терминального устройства или Сетевой Виртуальный Терминал (Network Virtual Terminal). Для краткости будем обозначать эту спецификацию NVT. NVT - это стандартное описание наиболее широко используемых возможностей реальных физических терминальных устройств. NVT позволяет описать и преобразовать в стандартную форму способы отображения и ввода информации. Терминальная программа ("user") и процесс ("server"), работающий с ней, преобразовывают характеристики физических устройств в спецификацию NVT, что позволяет, с одной стороны, унифицировать характеристики физических устройств, а с другой обеспечить принцип совместимости устройств с разными возможностями. Характеристики диалога диктуются устройством с меньшими возможностями.

Если взаимодействие осуществляется по принципу "терминал-терминал" или "процесс-процесс", то "user" - это сторона, инициирующая соединение, а "server" - пассивная сторона.

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

Симметрия взаимодействия по протоколу telnet позволяет в течении одной сессии программе-"user" и программе-"server" меняться местами. Это принципиально отличает взаимодействие в рамках telnet от традиционной схемы "клиент-сервер". Симметрия взаимодействия тесно связана с процессом согласования формы обмена данными между участниками telnet-соединения. Когда речь идет о работе на удаленной машине в режиме терминала, то возможности ввода и отображения информации определяются только конкретным физическим терминалом и договорной процесс сводится к заказу терминальной программой характеристик этого терминала. Гораздо сложнее обстоит дело, когда речь идет об обмене информацией между двумя терминальными программами в режиме "терминал-терминал". В этом случае каждая из сторон может выступать инициатором изменения принципов представления информации и здесь проявляется еще одна особенность протокола telnet. Протокол не использует принцип "запрос-подтверждение", а применяет принцип "прямого действия". Это значит, что если терминальная программа хочет расширить возможности представления информации, то она делает это (например, вставляет в информационный поток Esc-последовательности), если в ответ она получает информацию в новом представлении, то это означает, что попытка удалась, в противном случае происходит возврат к стандарту NVT.

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

В Unix-системах параметры терминалов обычно описаны в базе данных описания терминалов termcap. При инициировании telnet-соединения обычно именно эти параметры используются в процессе согласования формы представления данных. При этом из одной системы в другую обычно передается значение переменной окружения TERM. Если для этого значения переменной TERM имеются одинаковые описания в termcap, то проблем с представлением информации обычно не бывает; если терминал, заказанный в TERM, не определен, то берется стандартный терминал системы. При этом не все функции этого терминала будут задействованы. В процессе договора останутся только те, которые поддерживаются на обоих концах соединения. Часто можно столкнуться с ситуацией, когда значения переменных TERM на локальной и удаленной машинах совпадают, а информация на экране отображается не так, как этого бы хотелось. Скорее всего это вызвано различиями в описании данного устройства в базе данных termcap.

Сетевой виртуальный терминал (NVT) . Концепция сетевого виртуального терминала позволяет обеспечить доступ к ресурсам удаленной машины с любого терминального устройства. Под терминальным устройством понимают любую комбинацию физических устройств, позволяющих вводить и отображать информацию. Для тех кто знаком с универсальными машинами серии EC, такое определение терминала не является новым: в момент загрузки системы можно было назначить составную консоль, в которую могли входить устройство ввода с перфокарт и алфавитно-цифровое печатающее устройство (АЦПУ). В более ранних вычислительных комплексах такими терминалами могли быть системная печать и устройство чтения перфоленты (как на МИНСК-22) или телетайп (как на М-6000). Понятно, что за таким понятием терминала стоит требование устойчивости системы, которое было основополагающим для проекта ARPA.

В протоколе TELNET NVT определен как "двунаправленное символьное устройство, состоящее из принтера и клавиатуры". Принтер предназначен для отображения приходящей по сети информации, а клавиатура - для ввода данных, передаваемых по сети и, если включен режим "echo", вывода их на принтер. По умолчанию предполагается, что для обмена информацией используется 7-битовый US ASCII, каждый символ которого закодирован в 8-битовое поле. Любое преобразование символов является расширением стандарта NVT.

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

В моменты окончания печати на принтере NVT или отсутствия символов в буфере клавиатуры по сети должна посылаться специальная команда GA (Go Ahead). Смысл этой команды заключается в следующем: в реальных компьютерах линия "терминал-процесс" находится под управлением либо терминальной программы (ввод данных), либо печатающей программы. После выполнения своей функции каждая из них возвращает управление и освобождает линию. Обычно это происходит при работе с полудуплексными устройствами, такими как IBM-2741. Для того, чтобы протокол позволял работать и с этими устройствами, введен сигнал GA.

Остановимся более подробно на понятиях принтера и клавиатуры в концепции NVT.

Принтер имеет неограниченные ширину и длину страницы и может отображать все символы US ASCII (коды с 32 - 127), расширенный набор символов (коды с 128 - 255), а также распознает управляющие коды (с 0 - 31 и 127). Некоторые из них имеют специальные значения (таблица 3.1).

Клавиатура имеет возможность ввода всех символов US ASCII. Кроме этого клавиатура может генерировать специальные стандартные функции управления терминалом. Стандарт telnet определяет пять стандартных функций управления терминалом. Вообще говоря, эти функции могут или присутствовать на реальном терминале, и тогда они должны представляться в стандартной форме команды, или отсутствовать, и тогда заменяться командой NO (No-Оperation).

Команда "Прервать процесс" (Interrupt Process - IP). Данная команда реализует стандартный для многих систем механизм прерывания процесса выполнения задачи пользователя (Cntrl+C в Unix-системах или Cntrl+Break в MS-DOS). Следует заметить, что команда IP может быть использована и другим протоколом прикладного уровня, который может использовать telnet.

Команда "Прервать процесс выдачи" (Abort Output - AO). Многие системы позволяют остановить процесс, выдающий информацию на экран. Здесь следует понять отличие данной команды от IP. При выполнении IP прерывается выполнение текущего процесса пользователя, но не происходит очистка буфера вывода, т.е. процесс может быть остановлен, а буфер вывода будет продолжать передаваться на экран. Обычно это происходит при взаимодействии по медленным линиям связи. Пользователи персональных компьютеров прекрасно знакомы с этой особенностью буферизованных устройств, когда возникают проблемы с остановкой печати: пользователь уже прервал печать и очистил по команде print /t буфер печати на компьютере, а лазерный принтер продолжает изводить бумагу лист за листом. Это типичный пример непродуманного подхода к процессу управления терминальным устройством, который характерен для разработчиков MS-DOS. Для того, чтобы избежать подобного казуса и существует команда AO. Реально проверить ее может любой пользователь медленного телефонного канала связи - для этого можно запустить команду more для просмотра большого файла, после этого по команде Cntrl+C прервать ее - выдача информации на экран будет продолжаться, и после этого выдать из командной строки telnet команду AO, что прервет выдачу.

Команда "Ты еще здесь?" (Are You There - AYT). Назначение этой команды - дать возможность пользователю убедиться, что в процессе работы по медленным линиям он не потерял связи с удаленной машиной. В силу буферизации ввода и вывода может оказаться, что пользователь может вводить данные, а связь с удаленной машиной уже потеряна. В стандартной ситуации этот факт будет обнаружен только после нажатия клавиши "Enter". Telnet дает возможность убедится в наличии связи в любой момент времени.

Команда "Удалить символ" (Erase Character - EC). Многие системы обеспечивают возможность редактирования командной строки путем введения так называемых символов "забой" или удалением последнего напечатанного символа на устройстве отображения. В любом случае последний введенный в буфер символ удаляется. Команда EC призвана стандартизировать реализацию этого механизма.

Команда "Удалить строку" (Erase Line - EL). Данная команда аналогична EC, но удаляет целую строку ввода. Обычно выполнение этой команды приводит к очистке буфера ввода, т.к. при работе в режиме командной строки строка ввода только одна.

Синхронизация . В локальных системах синхронизация работы процессов обычно реализуются через механизм прерываний или, как в Unix, механизм сигналов. Это означает, что система имеет возможность вмешаться в процесс обработки данных практически в любой момент времени. В контексте взаимодействия программы обработки данных и терминальной программы это означает возможность прервать программу обработки или очистить один из буферов с/без отображением(я) информации из него. Именно к этому типу взаимодействия относятся команды IP и AO. Однако в сети сделать это не так просто, как в локальной вычислительной среде. Данные при передаче между машинами буферизуются и обмен происходит пакетами. Если бы команда "Прервать процесс" просто вставлялась в последовательность символов в пакете, то это приводило бы к эффекту запаздывания, т.е. после ввода пользователем команды "прервать процесс", а процесс будет продолжать выполняться пока не доберется до идентификатора команды IP в полученном пакете. Результат - бесполезно потраченное время. Поэтому механизм синхронизации telnet состоит из использования специальной формы пакета TCP (TCP Urgent notification) и команды DATA MARK (DM). Специальная форма TCP пакета используется для изменения процедуры обработки пакетов. Обычно пакет обрабатывается, начиная с первого символа пакета последовательно. В случае специальной формы пакета сначала происходит поиск "интересных" сигналов, а уже потом производится обработка пакета по стандартному сценарию. Команда DM обычно замыкает пакет и обозначает конец специальной обработки. Если TCP-пакет содержит специальные символы до DM, то порядок специальной обработки отменяется, а DM воспринимается как команда No- Operation (NO). Если специальные символы не найдены, то порядок специальной обработки пакетов продолжается. В этом смысле интересными сигналами или символами являются стандартные команды telnet IP, AO, AYT или другие команды, требующие немедленного выполнения.

Команды telnet имеют свой формат. Команда - это 2-байтовая последовательность, состоящая из Esc-символа (255) IAC (Interpret as Command) и кода команды (240-255). Команды, связанные с процедурой согласования параметров сеанса, имеют 3-х байтовый формат: третий байт - ссылка на устанавливаемую опцию.

Стандартным портом TCP для telnet является порт 23.

3.3.2. Интерфейс пользователя (telnet) и демон (telnetd)

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

3.3.2.1. Программа-сервер (telnetd)

Telnetd - это сервер, который обслуживает протокол TELNET. Обычно telnetd запускается через сервис Internet (inetd), в некоторых системах может быть запущен и вручную. Telnetd обслуживает TCP-порт 23, но может быть запущен и на другой порт.

Принцип работы сервера заключается в том, что он "слушает" порт TCP. В случае поступления запроса на обслуживание, telnetd назначает каждому удаленному клиенту псевдотерминал (pty) в качестве стандартного файла ввода (stdin), стандартного файла вывода (stdout) и стандартного файла ошибок (stderr).

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

Надо сказать, что telnetd реализует протокол TELNET частично. При работе по telnet никогда не используется сигнал Go Ahead (GA). Двоичный режим передачи данных можно реально использовать только для одинаковых операционных сред.

3.3.2.2. Программа-клиент (telnet)

Telnet - это интерфейс пользователя для работы по протоколу TELNET. Программа работает в двух режимах: в режиме командной строки (command mode) и в режиме удаленного терминала (input mode).

При работе в режиме удаленного терминала telnet позволяет работать с буферизацией (line-by-line) или без нее (character-at-a-time). При работе без буферизации каждый введенный символ немедленно отправляется на удаленную машину, откуда приходит "эхо". При буферизованном обмене введенные символы накапливаются в локальном буфере и отправляются на удаленную машину пакетом. "Эхо" в последнем случае также локальное.

Для переключения между режимом командной строки и режимом терминала используют последовательность Ctrl+], которая может быть изменена командами telnet (таблица 3.2).

Таблица 3.2, Основные команды режима командной строки telnet

Программу telnet можно использовать не только для работы по протоколу TELNET, но и для тестирования других протоколов, например SMTP:

Telnet host.domain.org 25

После установки соединения можно обмениваться командами протокола SMTP c сервером этого протокола.

В настоящее время часто доступ к удаленной машине Internet осуществляется не прямо, а через промежуточный сервер. Например, пользователь использует программу дозвона (dial-in) на персональном компьютере для доступа к Unix-машине, а затем telnet для доступа к другому компьютеру, подключенному к Internet. В этом случае также возможны несоответствия. Например, программа term90 из набора Norton Commander имеет экран не 24_80, а только 23_80. При эмуляции терминала vt100 это следует учитывать, т.к. в базе данных termcap для этого терминала определены значения 24_80. Дело в том, что при доступе по telnet две Unix-машины согласовывают свои возможности, а DOS-компьютер из этого процесса исключен. Для обеспечения правильной работы в базе данных termcap следует прописать терминал для такого доступа.

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

При обсуждении вопроса о доступе в режиме удаленного терминала нельзя обойти возможность доступа к системе по телефону, с использованием модема. Это совершенно другая, отличная от telnet технология. При обсуждении вопросов доступа к Internet в режиме Dial-IP уже обсуждались вопросы связанные с тем, что базовым методом доступа для режима IP является режим удаленного терминала, когда пользователь получает удаленный терминал (физически удаленный, но работающий точно также, как и локальный). В этом случае пользователь получает доступ не на виртуальные терминалы типа /dev/ttypX, а к устройствам типа /dev/ttydX, которые обычно используются для подключения модемов.

При подключении модема к компьютеру следует настроить терминал для работы с модемом, т.е. создать устройство /dev/ttydX, установить скорость обмена между портом компьютера и модемом, "залочить" модем.

Для создания устройства можно использовать скрипт MAKEDEV или команду mknode. В разных системах это делается по разному. Так в SCO или HP-UX устройство можно создать из интерфейса системного администратора.

Сцепление порта и устройства осуществляется через файл, выполняющийся в момент начальной загрузки в системе FreeBSD, например это делается через файл /etc/ttys:

# @(#)ttys 5.1 (Berkeley) 4/17/89 # # name getty type status comments # # This entry needed for asking password when init goes to single-user mode # If you want to be asked for password, change "secure" to "insecure" here console none unknown off secure # ttyv0 "/usr/libexec/getty Pc" cons25 on secure # Virtual terminals ttyv1 "/usr/libexec/getty Pc" cons25 on secure ttyv2 "/usr/libexec/getty Pc" cons25 on secure ttyv3 "/usr/libexec/getty Pc" cons25 off secure # Serial terminals ttyd0 "/usr/libexec/getty std.38400" dialup on secure ttyd1 "/usr/libexec/getty std.9600" unknown off secure ttyd2 "/usr/libexec/getty std.9600" unknown off secure ttyd3 "/usr/libexec/getty std.9600" unknown off secure # Pseudo terminals ttyp0 none network ttyp1 none network ttyp2 none network ttyp3 none network

В данном случае строка соответствующая терминалу ttyd0, используется для подключения модема. При этом на порте установлена скорость 38400, что позволяет подключать высокоскоростные модемы. Сам тип терминала dial-in описан в фале termcap. Скорость на модеме устанавливается согласно описаниям из файла gettytypes. Однако все это справедливо для систем a la BSD системах System 5 файлы настроек будут другие.

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

Рис. 3.21. Взаимодействие модема и последовательного порта

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

На схеме также изображено, так называемое "жесткое" управление соединением (Hardware Hadshaking), которое должно быть выбрано для управления модемом при его настройках. Принимающий вызовы модем должен быть сконфигурирован таким образом, чтобы он сам снимал трубку (ats0=5). Если кроме приема звонков от удаленных компьютеров телефон используется еще и как обычный телефон, то значение регистра s0 надо установить побольше.

Кроме того при работе с Unix следует принять во внимание тот факт, что некоторые системы работают с 7-битовыми терминалами. В этом случае при настройке программ пользователей в поле "Data Langth" следует указывать значение 7, а в поле Parity указывают Even.

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

• время использования процессора;
• размер используемого дискового пространства;
• время доступа к системе;
• каналы доступа к системе.

С точки зрения сетевого администрирования, все эти параметры подлежат если не ограничению, то строгому учету.

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

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

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

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

3.4. Обмен файлами. Служба архивов FTP

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

3.4.1. Типы информационных ресурсов

Информация в FTP-архивах разделена на три категории:

• Защищенная информация, режим доступа к которой определяется ее владельцами и разрешается по специальному соглашению с потребителем. К этому виду ресурсов относятся коммерческие архивы (например, коммерческие версии программ в архивах ftp.microsoft.com или ftp.bsdi.com), закрытые национальные и международные некоммерческие ресурсы (например, работы по международным проектам CES или IAEA), частная некоммерческая информация со специальными режимами доступа (частные благотворительные фонды, например).
• Информационные ресурсы ограниченного использования, к которым относятся, например, программы класса shareware (Trumpet Winsock, Atis Mail, Netscape, и т.п.). В данный класс могут входить ресурсы ограниченного времени использования (текущая версия Netscape перестанет работать в июне если только кто-то не сломает защиту) или ограниченного времени действия, т.е. пользователь может использовать текущую версию на свой страх и риск, но никто не будет оказывать ему поддержку.
• Свободно распространяемые информационные ресурсы или freeware, если речь идет о программном обеспечении. К этим ресурсам относится все, что можно свободно получить по сети без специальной регистрации. Это может быть документация, программы или что-либо еще. Наиболее известными свободно распространяемыми программами являются программы проекта GNU Free Software Foundation. Следует отметить, что свободно распространяемое программное обеспечение не имеет сертификата качества, но как правило, его разработчики открыты для обмена опытом.

Из выше перечисленных ресурсов наиболее интересными, по понятным причинам, являются две последних категории, которые, как правило, оформлены в виде FTP-архивов.

Технология FTP была разработана в рамках проекта ARPA и предназначена для обмена большими объемами информации между машинами с различной архитектурой. Главным в проекте было обеспечение надежной передачи и поэтому с современной точки зрения FTP кажется перегруженным излишними редко используемыми возможностями. Стержень технологии составляет FTP-протокол.

3.4.2. Протокол FTP

FTP (File Transfer Protocol или "Протокол Передачи Файлов") - один из старейших протоколов в Internet и входит в его стандарты. Обмен данными в FTP проходит по TCP-каналу. Построен обмен по технологии "клиент-сервер". На рисунке 3.22 изображена модель протокола.

В FTP соединение инициируется интерпретатором протокола пользователя. Управление обменом осуществляется по каналу управления в стандарте протокола TELNET. Команды FTP генерируются интерпретатором протокола пользователя и передаются на сервер. Ответы сервера отправляются пользователю также по каналу управления. В общем случае пользователь имеет возможность установить контакт с интерпретатором протокола сервера и отличными от интерпретатора пользователя средствами.

Рис. 3.22. Диаграмма протокола FTP

Команды FTP определяют параметры канала передачи данных и самого процесса передачи. Они также определяют и характер работы с удаленной и локальной файловыми системами.

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

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

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

Рис. 3.23. Соединение с двумя разными серверами и передача данных между ними

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

Режимы обмена данными

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

В общем случае, с точки зрения FTP, обмен может быть поточный или блоковый, с кодировкой в промежуточные форматы или без нее, текстовый или двоичный. При текстовом обмене все данные преобразуются в ASCII и в этом виде передаются по сети. Исключение составляют только данные IBM mainframe, которые по умолчанию передаются в EBCDIC, если обе взаимодействующие машины IBM. Двоичные данные передаются последовательностью битов или подвергаются определенным в процессе сеанса управления преобразованиям. Обычно, при поточной передаче данных за одну сессию передается один файл данных, при блоковом способе за одну сессию можно передать несколько файлов.

Описав в общих чертах протокол обмена, можно перейти к описанию средств обмена по протоколу FTP. Практически для любой платформы и операционной cреды существуют как серверы, так и клиенты. Ниже описываются стандартные сервер и клиент Unix-подобных систем.

3.4.3. Сервер протокола - программа ftpd

Команда ftpd предназначена для обслуживания запросов на обмен информацией по протоколу FTP. Сервер обычно стартует в момент загрузки компьютера. Синтаксис запуска сервера следующий:

Ftpd [-d] [-1] [-t timeout] d - опция отладки; 1 - опция автоматической идентификации пользователя; t - время пассивного ожидания команд пользователя.

Каждый сервер имеет свое описание команд, которое можно получить по команде help. Автоматическая идентификация пользователей осуществляется при помощи файла /etc/passwd. Пароль пользователя не должен быть пустым.

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

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

В директорию bin обычно записывается только одна команда ls. Данная команда позволяет выполнять просмотр текущей директории. Согласно правилам, анонимный пользователь должен иметь возможность выполнять только те команды, которые размещены в этой директории. Однако, в большинстве систем анонимный пользователь выполняет гораздо больший набор команд, при этом эти команды берутся из стандартных директорий системы. Способность этого пользователя создавать директории, удалять файлы и т.п. будет зависеть от прав, которые установлены администратором для той ветви, файловой системы, в которой располагается файловый архив FTP. Так, например, в Windows NT можно так назначить права, что при входе пользователя с консоли он сможет получить доступ к системе, а при доступе к своему архиву FTP пользователь таких прав не получает, точнее пользователь нормально идентифицируется и проходит аутентификацию, но после этого получает сообщение, что не обладает нужными правами для доступа к своей домашней директории. При этом данная проблема в рамках программ настроек Internet Information Services не решается. Приходится использовать стандартные средства Windows, определяющие эти права.

Другую опасность для системы представляют ссылки. Многие администраторы полагают, что взлом системы - это ситуация, когда злоумышленник проник в систему, однако это не так. Например, в классификации CERT тяжелый взлом - это, в том числе и выявление структуры файловой системы. В этом случае атакующий получает информацию о предмете атаки и может сосредоточить свои усилия на каком-то отдельном фрагменте системы.

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

Ниже приведена структура корня FTP-архива (рисунок 3.24).

Рис. 3.24. Структура ftp-архива

Общие положения

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

Основные тенденции развития средств удаленного управления

Стандартизация. Еще совсем недавно для удаленного управления корпоративными сетями применялись фирменные решения, отличающиеся использованием собственных протоколов передачи данных по телефонным сетям и собственных методов аутентификации удаленных пользователей, а также оригинальными способами предоставления ресурсов центральной сети. Естественно, это вызывало определенные проблемы и при необходимости «сращивания» двух сетей, имевших прежде различную конфигурацию средств управления сетью, и при подготовке специалистов, и в других ситуациях. Сейчас в системах управления работает все больше стандартных компонентов: протокол передачи данных PPP; «джентльменский набор» средств аутентификации - с помощью систем Kerberos, Novell NDS или MicrosoftDirectoryServices; предоставление информационных ресурсов удаленным пользователям с помощью службы WWW или тех же сервисов, которые работают и в локальной сети. Этот процесс облегчает взаимодействие серверов удаленного доступа с клиентами и сетевыми операционными системами, работающими в локальной сети. Хотя до полной стандартизации еще далеко (она, как всегда, является скорее целью), за последние несколько лет ситуация изменилась коренным образом.

Повышение скорости доступа. Основные усилия операторов телекоммуникационных сервисов сегодня направлены на преодоление для массовых пользователей ограничения в 56,2 Кбит/c, накладываемого аналоговыми модемами. Кроме того, передача информации через сеть Интернет является, мягко говоря, небезопасной. Поэтому идеальным вариантом было бы создание виртуальной частной сети - VPN (об этой технологии можно прочесть в КомпьютерПресс № 5"2001). Мы не будем подробно останавливаться на вопросах физического соединения пользователей или подсетей, рассмотрим их лишь в минимальном объеме.

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

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

В каких случаях это может быть опасно

Мы неоднократно писали о важности обеспечения безопасности при передаче информации по общей сети. Как показывает практика, случаи взлома сети все еще довольно часто встречаются. Повторим еще раз, какие опасности могут угрожать частной сети при использовании той или иной технологии передачи данных. Прежде всего это перехват информации при передаче. Здесь могут помочь средства шифрования, которые решают проблему лишь частично, поскольку применимы в основном к почте и передаче файлов. Решения же, позволяющие с приемлемой скоростью шифровать информацию в реальном времени (например, при непосредственной работе с удаленной базой данных или файл-сервером), пока малодоступны и дороги. Есть, конечно, средство защиты от несанкционированного доступа к сети - Firewall (межсетевой экран). Однако считать это панацеей не стоит - вспомните о вирусах и антивирусных программах. Любую защиту можно сломать, особенно если полученная информация окупает стоимость взлома. Таким образом, рекомендовать Internet как основу для систем, в которых требуется надежность и закрытость, можно лишь в крайнем случае и при использовании всех мер защиты, включая межсетевые экраны, шифрование канала и VPN. Кроме того, не стоит забывать и о человеческом факторе - о сотрудниках «внутри» и «снаружи» корпоративной сети. Но это уже тема отдельной статьи.

Отметим, что для организации удаленного доступа можно использовать технологии X.25 и Frame Relay, которые предоставляют ряд весьма интересных возможностей. Проблема несанкционированного доступа также может достаточно эффективно решаться средствами самой сети. Сегодня существуют средства шифрования, которые созданы специально для сетей X.25 и Frame Relay и позволяют работать на достаточно высоких скоростях. Такое оборудование производят компании Racal, Cylink, Siemens. Есть и отечественные разработки, созданные под эгидой ФАПСИ. Естественно, существуют разработки и для сетей на основе протокола IP, о которых мы неоднократно писали в статьях о безопасности.

Схемы удаленного управления сетью

Теперь перейдем к схемам удаленного управления сетью. На рис. 1 представлены основные схемы удаленного доступа, отличающиеся типом взаимодействующих систем: 1 - «терминал-компьютер»; 2 - «компьютер-компьютер»; 3 - «компьютер-сеть»; 4 - «сеть-сеть».

Первые три вида удаленного доступа часто объединяют понятием индивидуального доступа, а схемы доступа «сеть-сеть» иногда делят на два класса - ROBO (RegionalOffice/BranchOffice) и SOHO (SmallOffice/HomeOffice). Класс ROBO соответствует случаю подключения к центральной сети сетей средних размеров - сетей региональных подразделений предприятия, а классу SOHO - случаю удаленного доступа сетей небольших офисов и домашних сетей.

Особое место среди всех видов удаленного доступа к компьютеру занимает способ, при котором пользователь получает возможность удаленно работать с компьютером так же, как если бы он управлял им с помощью локально подключенного терминала. В этом режиме он может запускать программы на удаленном компьютере и видеть результаты их выполнения. При этом такой способ доступа принято разделять на терминальный доступ и на удаленное управление. Хотя это близкие режимы работы, но в описании продуктов удаленного доступа их не принято объединять в один класс. Обычно под терминальным доступом понимают символьный режим работы пользователя с удаленными многопользовательскими ОС - UNIX, VAXVMS, ОС мэйнфреймов IBM. В класс удаленного управления включают программы эмуляции графического экрана ОС персональных компьютеров - в первую очередь разных версий Windows, а в последнее время к этому классу можно отнести Linux-системы, Solaris и др.

Многие производители операционных систем предусмотрели в своих стеках протоколов средства терминального доступа пользователей к компьютерам по сети. Эти средства позволяют пользователю, работающему за компьютером, подключенным к сети, превратить экран своего монитора в эмулятор терминала другого компьютера, также подключенного к сети. Наиболее популярным средством такого типа является протокол telnet стека TCP/IP, появившегося в рамках операционной системы UNIX и с тех пор неразрывно с нею связанного.

В отличие от систем терминального доступа, превращающих компьютер пользователя в эмулятор экрана центрального компьютера, средства поддержки режима удаленного узла (remote node) делают вызывающую машину полноправным звеном локальной сети. Это достигается за счет того, что на удаленном компьютере работает тот же стек протоколов, что и в компьютерах центральной локальной сети, за исключением протоколов канального и физического уровня. На этом уровне вместо традиционных протоколов Ethernet или Token Ring работают модемные протоколы (физический уровень) и канальные протоколы соединений «точка-точка», такие как SLIP, HDLC и PPP. Эти протоколы используются для передачи по телефонным сетям пакетов сетевого и других протоколов верхних уровней. Таким образом, осуществляется полноценная связь удаленного узла с остальными узлами сети.

Сервис удаленного узла обеспечивает ему транспортное соединение с локальной сетью, поэтому на удаленном узле могут использоваться все сервисы, которые доступны локальным клиентам сети, например файл-сервис NetWare, сервис telnet или X-Window ОС UNIX, администрирование Windows NT.

Наибольшие сложности вызывает удаленное управление популярными настольными операционными системами семейства Windows, OS/2 и т.п. Это связано с тем, что для данных систем нет стандартного протокола эмуляции терминала, подобного telnet или X-Window для UNIX или LAT для VAXVMS. Кроме того, эти операционные системы наиболее знакомы конечному пользователю, и ему было бы очень удобно использовать привычный графический интерфейс Windows при управлении удаленным хостом. Поэтому именно средствам удаленного управления, встроенным в ОС семейств UNIX, Windows и NetWare, а также созданным третьими фирмами-разработчиками, будет посвящена оставшаяся часть этой статьи.

Средства для удаленного администрирования, встроенные в операционные системы

Семейство UNIX

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

В последнее время эта ситуация меняется в лучшую сторону - появляются клиент-серверные приложения, позволяющие удаленно администрировать UNIX/Linux-системы в графическом режиме. Примером может служить VNC Server для Suse Linux. Эти приложения заслуживают того, чтобы стать темой отдельной статьи.

А сейчас остановимся на telnet. Он входит в число стандартов, которых насчитывается три десятка на полторы тысячи рекомендуемых официальных материалов сети, называемых RFC (Request For Comments).

Изначально под telnet подразумевалась триада, состоящая из: telnet-интерфейса пользователя, telnet-процесса и telnet-протокола.

Эта триада обеспечивает описание и реализацию сетевого терминала для доступа к ресурсам удаленного компьютера.

Telnet строится как протокол приложения над транспортным протоколом TCP. При установке telnet-соединения программа, работающая с реальным терминальным устройством, и процесс обслуживания этой программы используют для обмена информацией сетевой виртуальный терминал (Network Virtual Terminal, NVT) - стандартное описание наиболее широко используемых возможностей реальных физических терминальных устройств. NVT позволяет описать и преобразовать в стандартную форму способы ввода и вывода информации. Терминальная программа (user) и процесс (server), работающий с ней, преобразуют характеристики физических устройств в спецификацию NVT, что позволяет обеспечить принцип совместимости устройств с разными возможностями. Характеристики диалога диктуются устройством с меньшими возможностями.

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

Взаимодействие по протоколу telnet симметрично, что позволяет в течение одной сессии программе-user и программе-server меняться местами. Это принципиально отличает взаимодействие в рамках telnet от традиционной схемы «клиент-сервер». Если же речь идет об обмене информацией между двумя терминальными программами в режиме «терминал-терминал», то каждая из сторон может выступать инициатором изменения принципов представления информации и при этом здесь проявляется еще одна особенность протокола telnet. Протокол использует не принцип «запрос - подтверждение», а принцип «прямого действия». Это значит, что если терминальная программа хочет расширить возможности представления информации, то она делает это (например, вставляет в информационный поток Esc-последовательности), а если в ответ она получает информацию в новом представлении, то это обозначает удачную попытку, в противном случае происходит возврат к стандарту NVT.

Однако у Telnet есть достаточно серьезные минусы - проблемы с безопасностью. Если вы разрешаете удаленные telnet-соединения с портами вашего сервера, то вам надо обратить особое внимание на тот факт, что человек, подключающийся к машине, взаимодействует с одной из программ-демонов. Он не имеет никаких прав на чтение/запись информации и не идентифицируется системой UNIX (вы не сможете его обнаружить командой who), но зато может давать команды этим демонам и, используя ошибки в программах или конфигурации, получить доступ к информации, хранящейся на сервере.

Семейство Windows

Сложность удаленного администрирования сервера Windows NT всегда удручала системных администраторов, сталкивавшихся с этой задачей. И хотя наиболее опытные освоили такие трюки, как использование RCMD (Remote Command Service, RCMD.EXE) в сочетании с программами regini или regedit, все равно удаленное администрирование Windows NT существенно отличается от своего локального аналога. В этом случае необходимо освоение специального инструментария, поскольку операционные системы персональных компьютеров всегда были тесно привязаны к локальным клавиатуре и дисплею. В самом деле, до недавнего времени большинство персоналок не подключалось к сети и, следовательно, не нуждалось во взаимодействии с другими клавиатурами или мониторами.

Этот пробел восполняется рядом продуктов третьих фирм-разработчиков, и речь о них пойдет ниже. Но существует также несколько пакетов для управления настольными системами на базе Windows, созданных разработчиками фирмы Microsoft.

Один из них - Systems Management Server (SMS) 2.0 (рис. 2), который тесно интегрирован с СУБД Microsoft SQL Server и программой Crystal Reports и имеет широкие возможности в плане управления информацией. Кроме того, очень привлекательна имеющаяся в SMS возможность планирования процесса сопровождения базы данных. Как и следовало ожидать, область диагностики неполадок в работе Windows великолепна.

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

Если же вам нужно всего лишь получить терминальный доступ к удаленному компьютеру и вы знакомы с работой telnet в UNIX-системах, то удобнее использовать такой продукт, как telnet-сервер, встроенный в Windows 2000 Professional.

По умолчанию запуск telnet-сервера отключен из-за очевидной угрозы безопасности. Чтобы запустить эту службу, воспользуйтесь командой: net start telnet

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

Семейство NetWare

Для управления рабочими станциями в состав операционной системы NetWare 5 входит пакет Z.E.N. works (Zero Effort Networking, - работа в сети с нулевыми усилиями). Хотя достичь нулевого уровня затрат при организации сети нельзя, пакет Z.E.N. works намного облегчает удаленное управление множеством клиентских станций. Сравнивая Z.E.N. works 2.0 с предыдущей версией, нельзя не отметить множество дополнительных возможностей последней версии, например: распространение приложений в зависимости от выполнения определенных условий, инвентаризация ПО рабочих станций и контроль его использования, генерация отчетов.

Для облегчения управления рабочими столами Windows пакет Z.E.N. works тесно интегрирован со службой справочника NDS. Этот пакет хорошо подходит также для территориально распределенных сервисных центров, серверы которых могут хранить копии разделов NDS.

С установкой Z.E.N. works у вас появляются следующие возможности:

• Поддержка рабочих станций. Пакет Z.E.N. works содержит агент регистрации рабочих станций (Workstation Registration), который автоматически регистрирует рабочие станции в том случае, если рабочая станция была обновлена в Novell Client с использованием Z.E.N. works или по крайней мере один раз регистрировалась в сети. После регистрации рабочих станций в службе NDS можно установить удаленное управление, распределяя соответствующие агенты пользователей. Имеются две возможности автоматического распространения агентов пользователей для рабочих станций Windows: с помощью терминально-резидентных программ (TSR) и с помощью NAL (Novell Application Launcher). Не важно, какая схема будет выбрана, пользователи в любом случае получат соответствующую NDS и права в файловой системе, чтобы принять инструкции удаленного управления.
• Управление рабочим столом. Системный администратор может настраивать рабочий стол пользователя, используя две специальные политики Z.E.N. works: системную политику пользователя (в пакете политик пользователя) и системную политику компьютера (в пакете политик рабочей станции). Соответственно системная политика пользователя позволяет настроить функции рабочего стола, которые будут доступны определенному пользователю, а политика компьютера - настроить параметры Windows каждой рабочей станции. Большим плюсом Z.E.N. works является возможность конфигурировать пользовательскую среду печати при помощи NDS. Можно автоматически загружать необходимый драйвер печати для каждого пользователя, когда он регистрируется в сети. Также существует возможность настраивать профили пользователей, то есть такие настройки рабочего стола, как обои, заставка и звуки, могут быть стандартизованы и разосланы всем пользователям предприятия.
• Управление приложениями. Пакет Z.E.N. works содержит специальную версию средства запуска приложений (NAL), позволяющую распространять сетевые приложения по рабочим станциям пользователей и управлять ими как объектами дерева NDS. Реализованы такие решения, как отказоустойчивость и выравнивание нагрузки, гарантирующие доступ пользователя к нужному приложению. Более того, если пользователь удалит со своего жесткого диска библиотеки необходимого приложения, а затем обратится к нему, NAL автоматически обнаружит пропавшие файлы и восстановит их.

Однако, несмотря на множество достоинств, у Z.E.N. works есть и некоторые недостатки, например: нет возможности автоматического создания процедуры удаления устанавливаемых приложений, а функция контроля использования приложений не охватывает локальные приложения, что делает невозможным контроль запуска игровых и других нежелательных программ на рабочих станциях.

Программные средства третьих фирм

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

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

Следующие три продукта для администрирования сети показательны в отношении расширения возможностей NT: Norton Network Series от компании Symantec, LANDesk Management Suite от Intel и Desktop Management Suite (DMS) от фирмы Veritas Software.

Пакет Norton Network Series от Symantec включает в себя целый ряд продуктов, таких как Norton Administrator Suite (NAS) и Expose. Средство NAS осуществляет инвентаризацию программных и аппаратных ресурсов, распространение программного обеспечения, контроль использования лицензионного ПО, защиту от вирусов и управление конфигурацией настольных компьютеров. NAS работает с целым рядом платформ, в том числе с Windows NT Server, NetWare, VINES компании Banyan и другими. Expose выполняет мониторинг системы в реальном времени и выдает предупреждения о неполадках на серверах NetWare, NT и VINES. Он поддерживает административную консоль NAS и, кроме того, SNMP.

LANDesk от Intel во многом похож на SMS от компании Microsoft, о котором уже говорилось в этой статье. На практике LANDesk стоит использовать в сети NetWare, имеющей несколько серверов Windows NT, в то время как SMS логично применять в сети NT с несколькими серверами NetWare. LANDesk обеспечивает поддержку DMI (Desktop Management Interface), а также имеет множество других сервисов, в числе которых - инвентаризация программных и аппаратных ресурсов, контроль использования лицензионного ПО и распространение программного обеспечения. Помимо этого LANDesk поддерживает управление принтерами рабочих станций и антивирусное ПО Norton AntiVirus от фирмы Symantec, которое устанавливается вместе с агентом управления. И наконец, этот продукт имеет инструментарий мониторинга сети, позволяющий контролировать характер использования сети, выявлять сбои, а также, посылать аварийные сигналы системам управления на серверах NetWare и Windows NT. Служба удаленного управления рабочей станцией используется для организации справочной системы (help desk).

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

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

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

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

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

КомпьютерПресс 7"2001