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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Использование электронных ключей как средства аутентификации пользователей. Анализ методов идентификации и аутентификации с точки зрения применяемых в них технологий. Установка и настройка средств аутентификации "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

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

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

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

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

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

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

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

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

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

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

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

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

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

IPsec VPN;
"классический" сценарий применения защиты транспортного уровня на базе протоколов SSL или TLS;
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-продуктах...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Другой вопрос, который часто задают применительно к схеме, показанной на рис. 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 удаленного доступа. Поэтому в заключение разумно перечислить основные принципы, следуя которым вы не "промахнетесь" при разработке конкретных систем:

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

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

Литература

RFC 4026, L. Andersson, T. Madsen, Acreo AB, " Provider Provisioned Virtual Private Network (VPN) Terminology ", March 2005.
SAFE VPN IPSec Virtual Private Networks in Depth. Cisco Systems, Inc., 2004.
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, которое не стареет с выходом новой версии протокола.

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

Команда	Назначение
open host	Начать telnet-сессию с машиной host по порту port. Адрес машины можно задавать как в форме IP-адреса, так и в форме доменного адреса
close	Завершить telnet-сессию и вернуться в командный режим. Однако в некоторых системах, если telnet был вызван с аргументом, close приведет к завершению работы telnet
quit	Завершить работу telnet
z	"Заморозить" telnet сессию и перейти в режим интерпретатора команд локальной системы. Из этого режима можно выйти по команде Exit
mode type	Если значение type line, то используется буферизованный обмен данными, если character - то обмен не буферизованный
? help	Список команд или описание конкретной команды
send argument	Данная команда используется для ввода команд и сигналов протокола TELNET, которые указываются в качестве аргумента. Например: send ao - посылает команду прервать выдачу на принтер NVT

Программу 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-архива