Дипломная работа: Защита информации виртуальных частных сетей

Операционные системы Microsoftв Windowsв 95, Windows 98, Windows NTв и Windows 2000 позволяют организовывать простую, безопасную и высокорентабельную связь, преодолевая тем самым географические и государственные границы на пути развития бизнеса. Одной из важнейших особенностей коммуникационных платформ на базе Windows, несомненно, является поддержка виртуальных частных сетей (ВЧС).

Виртуальные частные сети находят сегодня все более широкое распространение. Этому способствует два обстоятельства: экономичность такого вида связи и одновременно – высокая безопасность инфраструктуры частных сетей. Используя ВЧС, и командированный работник, и служащий филиала может подключиться к корпоративной сети с обычного локального телефона, что намного дешевле выхода на линии междугородной связи или абонирования «бесплатного» номера 800, не говоря уж об аренде выделенных каналов связи. Безопасность же ВЧС достигается за счет организации так называемых туннельных подключений, позволяющих войти в корпоративную сеть только тем пользователям, которые прошли аутентификацию. Средства ВЧС, предлагаемые корпорацией Microsoft, обеспечивают шифрование информации с применением 128-битового ключа. В целом виртуальную частную сеть можно представить как своеобразный туннель, проложенный через Интернет или другую общедоступную сеть. По безопасности и функциональности туннелирование практически ничем не уступает частным сетям. Под туннелированием понимается включение информационного пакета в обычный IP-пакет (так называемое инкапсулирование) и его передача в таком виде по общедоступной сети. Когда инкапсулированный пакет поступает в сеть получателя, например, в корпоративную локальную вычислительную сеть (ЛВС), внешняя IP-оболочка с него снимается, после чего обработка информации производится обычным способом.

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

Корпорация Microsoft была в числе пионеров интеграции средств ВЧС и сейчас продолжает активно работать в этом направлении. Совместно со своими отраслевыми партнерами и Целевой группой технической поддержки Интернета IETF корпорация совершенствует технологии виртуальных частных сетей и средства обеспечения их безопасности. Настоящий документ посвящен вопросам защиты ВЧС, оценке угрозы их безопасности и различным способам ее устранения, которые предлагает Microsoft.

Microsoft разработала широкий спектр средств организации ВЧС, способных удовлетворить самые разные запросы в области защиты информации. Одним из них является протокол PPTP (Point-to-Point Tunneling Protocol – протокол туннелирования между узлами), призванный свести к минимуму общую стоимость владения системой. Корпорация встроила его в свои операционные системы Windows 95, Windows 98 и Windows NT 4.0, а независимые производители сделали этот протокол доступным пользователям Windows 3.1 и Macintosh. Протокол PPTP совместим с широким кругом аппаратных платформ, позволяет производить аутентификацию по паролю и не требует инфраструктуры сертификации.

Чтобы обеспечить еще больший уровень безопасности, корпорация включает в операционную систему Windows 2000 собственную реализацию протоколов L2TP (Layer 2 Tunneling Protocol – протокол туннелирования канального уровня) и IPSec (Internet Protocol Security – протокол безопасности в Интернете). Правда, применение этих средств предъявляет повышенные требования к системам: для них необходимо развертывание PKI (Public Key Infrastructure – инфраструктура с открытыми ключами) и применение центральных процессоров класса Pentium.

1 Основы безопасности ВЧС

Туннель ВЧС служит для транспортировки информации, не отвечающей стандартам адресации Интернета. Чтобы доставить такие данные от одного конца туннеля к другому, программа помещает (инкапсулирует) их в стандартные IP-пакеты, которые затем пересылаются по промежуточным сетевым каналам от одной сети (или одиночного клиента) к другой. Весь процесс инкапсулирования и пересылки пакетов называется туннелированием, а логическое подключение, используемое для их передачи, – туннелем. Таким образом, туннель представляет собой логический канал связи, проложенный через Интернет или любую другую промежуточную сеть. Удаленные пользователи при этом играют роль виртуальных узлов той сети, с которой они соединены туннелем.

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

Защита информации виртуальных частных сетей

Рисунок 1 - Концептуальная модель ВЧС

Инкапсулирование, как и шифрование потоков данных, жизненно необходимы для передачи информации через Интернет. Функции инкапсулирования, выполняемые с помощью протоколов PPTP и L2TP, упрощают организацию многопротокольной связи, так как позволяют пересылать по IP-сетям пакеты данных, созданные на основе других протоколов. Благодаря этому удаленный клиент может применять для подключения к корпоративной ЛВС любой протокол и при этом пользоваться всеми преимуществами Интернета.

1.1 Пользовательские процессоры

Средства организации ВЧС, разработанные Microsoft, позволяют подключать к серверам на базе Windows NT так называемые пользовательские процессоры (front-end processor, ПП), управляющие доступом клиентов в сеть данного сервера. Применение таких посредников дает возможность устанавливать туннельные подключения даже тем клиентам, которые не оснащены средствами ВЧС. Пользователь может и не знать, подключился он к серверу напрямую, или через ПП, создавший для него туннель. Благодаря этому в ВЧС Microsoft обеспечивается «прозрачный» доступ к клиентам РРР, позволяющий им работать в средах Unix, Win 16, MS-DOS®, а также взаимодействовать с клиентами Macintosh и другими.

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

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

1.2 Заказные и принудительные туннели

Существует два типа туннелей ВЧС – заказные (voluntary) и принудительные (compulsory). Для создания заказного туннеля необходимо, чтобы клиент был оснащен средствами создания ВЧС, тогда как принудительный туннель организуется при посредничестве пользовательского процессора.

1.2.1 Заказное туннелирование

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

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

1.2.2 Принудительное туннелирование

Если нужно проложить туннель через Интернет, но клиент не оснащен средствами ВЧС, он может подключиться к пользовательскому процессору поставщика услуг. Благодаря этому создается так называемый принудительный туннель, для которого клиенту не нужна ни поддержка протоколов PPTP и L2TP, ни вспомогательное ПО. Все это имеется на пользовательском процессоре. Как и при заказном туннелировании, здесь действует условие: ПП и сервер туннелирования должны применять в каждом индивидуальном подключении один и тот же протокол ВЧС (PPTP или L2TP).

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

2 ВЧС на основе туннельного протокола PPTP (Point-to-Point Tunneling Protocol)

Протокол PPTP представляет собой открытый отраслевой стандарт. Создание этого протокола стало результатом объединенных усилий целого ряда известных производителей сетевых компонентов, включая Ascend Communications, 3Com/Primary Access, ECI Telematics, US Robotics и Microsoft. Эти компании основали Форум PPTP, результаты работы которого стали широко известны в 1996 году, когда на рассмотрение Группы целевой технической поддержки Интернета (IETF) был передан проект новой спецификации.

РРТР - протокол, который позволяет выполнять туннелирование РРР-соединений по IP-сети путем создания VPN. Таким образом, удаленный компьютер в сети Х может туннелировать трафик на шлюз в сети У и имитировать подключение, с внутренним IP-адресом, к сети У. Шлюз получает трафик для внутреннего IP-адреса и передает его удаленной машине в сети Х. Существуют два основных способа использования РРТР: по Интернет и по коммутируемым соединениям.

Функционирование РРТР заключается в инкапсулировании пакетов виртуальной сети в пакеты РРР, которые в свою очередь, инкапсулируются в пакеты GRE (Generic Routing Incapsulation), передаваемые по IP от клиента к шлюзу - серверу РРР и обратно. Совместно с каналом инкапсулированных данных существует управляющий сеанс на базе TCP. Пакеты управляющего сеанса позволяют запросить статус и сопровождать сигнальную информацию между клиентом и сервером. Канал управления инициируется клиентом на сервере на ТСР-порте 1723. В большинстве случаев это двунаправленный канал, по которому сервер посылает запросы на сервер и наоборот.

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

Microsoft РРТР является частью ОС Windows NT Server, данное программное обеспечение можно бесплатно получить с Web-сайта Microsoft. Подключение осуществляется с помощью панели управления и редактора реестра. Данная реализация РРТР широко используется в коммерческих применениях VPN, например Aventail и Freegate именно потому, что входит в состав ОС Microsoft.

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

Текстовый пароль: Клиент передает серверу пароль в открытом виде.

Хэшированный пароль: Клиент передает серверу хэш пароля

Вызов/Отклик: Аутентификация сервера и клиента с использованием протокола MS-CHAP (вызов/отклик), что описано в параграфе 4.

Третий вариант называется в документации для пользователей "Аутентификация Microsoft", для шифрования пакетов РРТР его надо разрешить. При выборе любого из двух других вариантов шифрование неосуществимо. Кроме того, возможность шифрования (40- или 128-разрядное) гарантируется только в том случае, если клиент использует Windows NT. Некоторые клиенты Windows 95 не могут поддерживать зашифрованные сеансы.

Протокол PPTP тесно интегрирован со службой удаленного доступа (Remote Access Services), входящей в Windows NT Server и Windows 98, а также с дополнительным компонентом создания сетей с доступом по коммутируемым каналам Dial-Up Networking 1.2 Upgrade для операционной системы Windows 95.

Защита информации виртуальных частных сетей

Рисунок 2 – туннель с использованием протокола PPTP

2.1 Практические аспекты обеспечения безопасности

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

За все время эксплуатации виртуальных частных сетей на базе Windows клиенты ни разу не пожаловались на недостаточную их защищенность. Но Microsoft не успокаивается на достигнутом и продолжает совершенствовать технологию Windows Networking and Communications (организация сетей и связи в среде Windows). Очередным шагом в этом направлении стал выпуск дополнительного программного пакета PPTP Performance and Security Upgrade (обновление для повышения производительности и безопасности на основе PPTP) для клиентов и серверов, работающих под управлением Windows.

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

2.3 Развитие технологии

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

Из новшеств Microsoft в области технологий создания ВЧС на базе PPTP можно упомянуть:

более совершенную аутентификацию в протоколе MS-CHAP 2;

повышение надежности аутентификации по паролю;

повышение стойкости шифрования по протоколу MPPE (Microsoft Point-to-Point Encryption – шифрование между узлами).

2.4 Совершенствование аутентификации в протоколе MS-CHAP 2

Протокол MS-CHAP (Microsoft Challenge-Handshake Authentication Protocol – протокол взаимной аутентификации Microsoft) содержит механизм аутентификации, необходимый для проверки регистрационных данных пользователя в доменах Windows NT. Созданные с его помощью сеансовые ключи применяются для шифрования данных пользователя, как это описано в разделе, посвященном протоколу MPPE.

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

Протокол MS-CHAP 2 описывает порядок одностороннего преобразования пользовательского пароля, алгоритм генерации запроса сервером, алгоритм генерации запроса клиентом и дополнительные данные, включаемые в сообщение Success (Аутентификация успешна). Если клиент MS-CHAP 2 не смог идентифицировать сервер, он отключается.

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

В MS-CHAP 2 предусмотрены дополнительные коды ошибки, в том числе код истечения срока действия пароля, а также новые шифрованные клиент-серверные сообщения, благодаря которым пользователь может изменить свой пароль. В новой реализации протокола Microsoft первичный ключ, необходимый для последующего шифрования данных по протоколу MPPE, генерируется клиентом и сервером независимо друг от друга.

Ранее протокол Microsoft PPTP допускал применение и других, менее надежных механизмов аутентификации в ВЧС. Теперь же он использует только MS-CHAP, что значительно повышает безопасность аутентификации.

Повышение надежности аутентификации по паролю

Как уже отмечалось, при подключении к PPTP-серверу, работающему под управлением Windows NT, клиенты на базе Windows проводят двустороннюю аутентификацию по протоколу MS-CHAP. Чтобы не допустить перехвата передаваемого пароля, используется функция хеширования (пароли Windows NT могут иметь длину до четырнадцати 16-битовых символов из одного набора Unicode; строчные и прописные буквы в них различаются).

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

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

2.5 Обязательное использование паролей Windows NT

Microsoft выпустила дополнение к клиентским и серверным PPTP-компонентам для Windows NT, позволяющее повысить надежность применяемых паролей. С его помощью можно настроить систему таким образом, что она просто не допустит аутентификации по старым паролям, и пользователям волей-неволей придется перейти на пароли Windows NT. К тому же это дополнение дает возможность изменить конфигурацию PPTP-клиентов Windows NT, запретив аутентификацию по паролям LAN Manager.

2.5.1 Соблюдение правил выбора пароля

Microsoft рекомендует своим клиентам принять все необходимые меры, чтобы в их сетях применялись только сложные пароли повышенной стойкости, содержащие случайную комбинацию строчных и прописных букв, цифр и знаков препинания. Для обеспечения безопасности сети крайне важно регулярно обновлять пароли. В соблюдении этих правил способна помочь Windows NT. Все пакеты обновления для Windows NT 4.0, начиная с Service Pack 2, снабжаются инструментальными средствами администрирования, которые обеспечивают выполнение правил безопасности и лучшее управление паролями.

2.5.2 Основы правильного использования паролей

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

К числу плохих следует однозначно отнести пароли, которые:

состоят исключительно из словарных слов;

используют буквы только одного регистра (строчные или прописные);

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

А вот требования, которым должен удовлетворять надежный пароль:

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

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

текст не должен содержать осмысленных слов и личных имен.

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

2.6 Повышение стойкости шифрования по протоколу MPPE

Шифрование информации создает еще один уровень защиты виртуальных частных сетей, созданных на базе протокола PPTP, который необходим на случай перехвата пакетов ВЧС. Правда, такая возможность носит скорее теоретический характер и весьма маловероятна на практике. Тем не менее, можно представить себе злоумышленника, сумевшего разместить между клиентом и сервером собственный компьютер. Если его машине удастся предстать перед клиентом в образе сервера PPTP, она сможет заполучить весь его трафик. Уязвимость для подобных атак свойственна не только продуктам Microsoft, – подобная опасность существует при любой системе аутентификации, где не предусмотрен взаимный обмен запросами и ответами на них. Такую возможность полностью исключает лишь применение протокола MS-CHAP 2, обеспечивающего взаимную аутентификацию участников сеанса связи.

Шифрование по протоколу MPPE с 128- и 40-битовым ключом полностью защищает все данные, циркулирующие между клиентом и сервером. А это значит, что даже вклинив между ними свой компьютер, злоумышленник не сможет прочесть передаваемую информацию – для этого ему сначала придется заполучить секретный ключ.

В основу протокола PPTP положен алгоритм шифрования RSA RC4, который обеспечивает самую высокую стойкость, разрешенную правительством США для коммерческих систем. В Северной Америке шифровать сообщения можно посредством ключа длиной 128 бит, в других же странах его длина не может превышать 40 бит. При использовании протокола MS-CHAP 2 для связи в прямом и обратном направлении генерируется два отдельных ключа, причем по умолчанию эти ключи меняются при передаче каждого пакета. Все это еще более затрудняет «силовые» атаки на сеть.

3 Криптоанализ туннельного протокола PPTP

Обнаружено, что протокол аутентификации Microsoft слаб и уязвим путем атаки по словарю; большинство паролей можно вскрыть в течение нескольких часов. Обнаружено, что способы шифрования с использованием 40- и 128-разрядных ключей одинаково слабы и открыли ряд заложенных в реализацию неразумных идей, которые позволяют осуществлять другие атаки на данный шифр. Можно открывать соединения через firewall, нарушая правила переговоров РРTР, и можем проводить различные атаки отказа в обслуживании на тех, кто использует Microsoft PPTP.

3.1 Криптоанализ функций хэширования паролей Windows NT

В ОС Microsoft Windows NT для защиты паролей используются две однонаправленные хэш-функции: хэш Lan Manager и хэш Windows NT. Функция хэша Lan Manager была разработана Microsoft для операционной системы IBM OS/2, она была интегрирована в Windows for Workgroups и частично в Windows 3.1. Данная функция используется в некоторых протоколах аутентификации перед Windows NT. Хэш Windows NT был разработан специально для ОС Microsoft Windows NT. Функция хэша Lan Manager основана на алгоритме DES; Функция хэша Windows NT основана на односторонней хэш-функции MD4. Обе эти функции используются во многих протоколах аутентификации Windows NT, а не только в РРТР.

Функция хэша Lan Manager вычисляется следующим образом:

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

Замена всех символов нижнего регистра на символы верхнего регистра. Цифры и специальные символы остаются без изменений.

Разбиение 14-байтовой строки на две семибайтовых половины.

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

Слияние двух строк для создания одного 16-разрядного значения хэш-функции.

Словарные атаки на функцию хэша Lan Manager легко достигают успеха по следующим причинам:

Большинство людей выбирают легко угадываемые пароли.

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

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

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

Функция хэша Windows NT вычисляется следующим образом:

Преобразование пароля, длиной до 14 символов, с различением регистров в Unicode.

Хэширование пароля с помощью MD4, получение 16-символьного значения хэш-функции.

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

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

3.2 Криптоанализ MS-CHAP

РРР содержит различные способы обработки аутентификации. Одним из способов является протокол аутентификации вызов-рукопожатие (СНАР). Реализация PPP СНАР компанией Microsoft (MS-CHAP) почти совпадает с методом аутентификации, используемым для аутентификации клиентов в Windows-сетях.

MS-CHAP функционирует следующим образом:

Клиент запрашивает вызов сетевого имени.

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

Клиент вычисляет хэш-функцию Lan Manager, добавляет пять нулей для создания 21-байтовой строки и делит строку на три семибайтовых ключа. Каждый ключ используется для шифрации вызова, что приводит к появлению 24-разрядного шифрованного значения. Оно возвращается серверу как отклик. Клиент выполняет то же самое с хэш-функцией Windows NT.

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

Сервер может выполнять сравнение по хэш-функции Windows NT или по хэш-функции Lan Manager; результаты должны совпадать. Хэш, используемый сервером, зависит от конкретного флага в пакете. Если флаг установлен, то сервер выполняет тестирование с помощью хэш-функции Windows NT; в противном случае тестирование выполняется с помощью хэш-функции Lan Manager.

Протокол вызова/отклика является стандартным; использование случайного вызова имени делает невозможными словарные атаки на MS-CHAP и файл записанных хэш-функций от паролей. В то же время, поскольку даже в Windows NT-сетях используются оба значения хэш-функции, можно в каждом случае атаковать более слабую хэш-функцию Lan Manager. Поскольку ответ клиента разбит на три части, и каждая часть шифруется независимо от других, можно атаковать сам протокол MS-CHAP.

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

Атака может быть существенно ускорена за счет активного использования предварительных вычислений и тщательного исследования слабостей хэш-функции Lan Manager и протокола MS-CHAP. Далее приводятся подробности оптимизированной атаки:

Р0-Р13 - байты пароля. Н0-Н15 - байты хэш-функции Lan Manager, которая преобразуется в 21-байтовый ключ К0-К20. S- фиксированная константа, используемая в хэш-функции Lan Manager. Вызов С и 24-байтовый отклик Ro-R23. Злоумышленник может знать C и R и хочет найти Р.

1) Можно попробовать все возможные комбинации К14, К15. Правильное значение выделяется, когда С превращается в R16, ..., R23 с ключом К14, К15, 0,0,0,0,0. На это уходит примерно 215 операций.

2) Можно попробовать вероятные значения Р7,...,Р13. Неверные значения можно быстро отбросить путем шифрования S и проверки совпадения последних двух байт полученного значения с К14 и К15. (Так остается только один вариант из каждых 216). Каждый оставшийся вариант Р7,...,Р13 предоставляет значение-кандидат для К8,...,К13. Чтобы проверить значение-кандидат, проверьте все возможные значения К7, чтобы увидеть, есть ли такое, при котором С шифруется в R8,...,R15 при значении-кандидате К8,...,К15. Если есть такое К7, то догадка для Р7,...,Р13 почти наверняка верна. Если нет, то надо выбрать другое значение для Р7,...,Р13. Если существуют N вероятных вариантов Р7,...,Р13, то подбор верного значения можно провести за N тестовых шифрований.
Поскольку в протоколе нет индивидуальной настройки, эта атака может быть существенно ускорена с помощью замены время/память. Если есть N заранее вычисленных тестовых шифрований, то восстановление верного значения Р7,...,Р13 потребует N/216 операций.

После нахождения Р7,...,Р13, восстановление Р0,...,Р6 требует М попыток, где М - число вероятных значений Р0,...,Р6. Опять же, поскольку нет индивидуальной настройки, атака может быть выполнена за N/28 попыток при М предварительно вычисленных значениях.

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

3.3 Криптоанализ МРРЕ

Протокол шифрования в одноранговых сетях (МРРЕ) обеспечивает методологию для шифрования пакетов РРТР. Он предполагает существование секретного ключа, известного обоим участникам соединения, и использует поточный шифр RC4 с 40- либо 128-разрядным ключом. Такой метод установки использования МРРЕ является одной из функций протокола управления сжатием РРР (ССР). После установки режима работы начинается сеанс РРР по передаче пакетов зашифрованных данных. Важно отметить, что шифруются только те пакеты РРР, номера протоколов которых лежат в диапазоне 0x0021-0x00fa. Все остальные пакеты передаются без шифрования, даже если шифрование разрешено. Типы пакетов, шифрование которых осуществляется/не осуществляется, регламентируются документом RFC 1700. Для любых пакетов не обеспечивается аутентификация.

В МРРЕ 40-битовый ключ RC4 определяется следующим образом:

Генерация определяющего 64-битового ключа из хэш-функции Lan Manager пароля пользователя (известного пользователю и серверу) с помощью SHA.

Установка старших 24 бит ключа в значение 0xD1269E.

128-битовый ключ RC4 определяется следующим образом:

Объединение хэша Windows NT и 64-битового случайного значения, выданного сервером при работе по протоколу MS-CHAP. Данное число посылается клиенту по протоколу обмена, потому оно известно и клиенту, и серверу.

Генерация определяющего 128-битового ключа из результатов предыдущего этапа с помощью SHA.

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

Генерация определяющего ключа - 64-битового для 40-битового шифрования и 128-битового для 128-битового шифрования - путем хэширования предыдущего ключа и исходного ключа с помощью SHA.

Если требуется 40-битовый ключ, то установка старших 24 бит ключа в значение 0xD1269E.

Длина типичного пакета РРТР составляет 200 байт, включая заголовок.

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

3.3.1 Восстановление ключа

В МРРЕ степень защиты ключа не превышает степень защиты пароля. Большая часть паролей имеет существенно меньше 40 бит безопасности и раскрываются с помощью словарных атак. Хэш-функция Lan Manager еще боле уязвима: с учетом максимальной длины порции, ограниченного алфавита и отсутствия символов нижнего регистра, невозможно сгенерировать 128-битовый ключ, даже если пользователь хочет это сделать. В документации по МРРЕ описывается флаг для вычисления 40-битового ключа RC4 на основании хэш-функции Windows NT, а не Lan Manager, но эта функция еще не реализована. Нет способов вычисления 128-битового ключа RC4 на основании хэш-функции Windows NT, хотя такой вариант был бы более безопасным (хотя существенно менее безопасным, чем 128-битовый случайный ключ.)

В любом случае, общая степень защиты составляет не 40 или 128 бит, а количество бит энтропии пароля. На основании экспериментальных данных получено, что английскому языку свойственна энтропия 1,3 бита на символ. Изменения регистра, цифры и специальные символы существенно повышают это значение. Любая атака, которая использует словарь слабых паролей, может быть способна прочитать зашифрованный МРРРЕ трафик. Кроме того, стилизованные заголовки в пакете РРР облегчают сбор известных текстов и базы для проверки угаданного ключа.

40-битовый алгоритм RC4 подвержен более серьезным уязвимостям. Поскольку не предусмотрена индивидуальная настройка, атакующий может подготовить словарь зашифрованных заголовков РРР, а затем быстро найти данный зашифрованный текст в словаре. При поиске мест в пакетах МРРЕ, где может содержаться незашифрованный текст, атакующий может воспользоваться множеством связей по SMB и NetBIOS, которые происходят при стандартных соединениях Microsoft.

Более того, тот же 40-битовый ключ RC4 генерируется всякий раз, когда пользователь инициализирует протокол РРТР. Поскольку RC4 представляет собой способ шифрования с обратной связью по выходу, то просто взломать шифр за два сеанса. Серьезная уязвимость отмечается в большей части свежих спецификаций МРРЕ, хотя она исчезла из предыдущей версии. Ни в одной версии документации Microsoft не указано, что один и тот же ключ используется как в прямом, так и в обратном направлении, что гарантирует, что для шифрования двух разных текстов используется один и тот же поток ключей.

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

3.3.2 Атаки переворота битов

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

3.3.3 Атака путем ресинхронизации

Если в процессе передачи теряется пакет, либо приходит пакет с неверным номером в заголовке МРРЕ, то происходит ресинхронизация ключа. Сторона, принявшая неверный пакет, посылает отправителю запрос на ресинхронизацию. По принятию данного запроса, отправитель реинициализирует таблицы RC4 и устанавливает бит "сброшен" (flushed) в заголовке МРРЕ. Если система обнаруживает в пакете установленный бит "сброшен", она реинициализирует свои таблицы RC4 и устанавливает счетчик пакетов в соответствии с полученным значением.

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

3.4 Другие атаки на MS-PPTP

Несмотря на то, что атаки на протоколы MS-CHAP и МРРЕ приводят к полному отрицанию полезности и безопасности MS PPTP, необходимо упомянуть о нескольких интересных атаках.

3.4.1 Пассивный мониторинг

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

Путем установки стандартных средств просмотра и расшифровки общественных линий связи от серверов Microsoft PPTP была получена следующая информация:

IP-адрес клиента

IP-адрес сервера

Количество доступных на сервере виртуальных каналов РРТР

Версия RAS клиента

Имя клиента NetBIOS

Идентификация производителя клиента

Идентификация производителя сервера

IP-адрес клиента во внутреннем виртуальном туннеле

Внутренние DNS-сервера, обслуживающие клиента

Имя пользователя на клиенте

Достаточно информации для получения значений хэш-функций паролей пользователей

Достаточно информации для получения начального значения МРРЕ

Текущее значение шифрованного пакета для клиента перед реинициализацией RC4

Текущее значение шифрованного пакета для сервера перед реинициализацией RC4

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

3.4.2 Перехват переговоров РРР

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

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

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

3.4.3 Потенциальные утечки информации на клиенте

Клиент Windows 95 не выполняет требуемую очистку буферов, и потому допускается утечка информации в сообщениях протокола. Хотя в документации РРТР сказано, что в пакете PPTP_START_SESSION_REQUEST символы после имени компьютера и производителя должны быть сброшены в 0х00, Windows 95 этого не делает.

080: 0000 6c6f 6361 6c00 0000 3e1e 02c1 0000 ..local...>.....

096: 0000 85c4 03c1 acd9 3fc1 121e 02c1 2e00 ........?.......

112: 0000 2e00 0000 9c1b 02c1 0000 0000 0000 ................

128: 0000 88ed 3ac1 2026 02c1 1049 05c1 0b00 ....:. &...I....

144: 0000 3978 00c0 280e 3dc1 9c1b 02c1 041e ..9x..(.=.......

160: 02c1 0e00 0000 121e 02c1 2e00 0000 2e00 ................

176: 0000 3dad 06c1 74ed 3ac1 1c53 05c1 9c1b ..=...t.:..S....

192: 02c1 041e 02c1 0e00 0000 121e 02c1 2e00 ................

208: 0000 ..

Выше показаны символы, содержащиеся после имени компьютера и строки производителя. В байтах 82-86 содержится имя компьютера, которое для клиента Windows 95 всегда равняется "local". Байт 113 - то место, где должна содержаться строка производителя. При просмотре аналогичного пакета Windows NT обнаружено, что все символы "мусора" сброшены в 0х00.

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

3.5 Выводы

Реализация РРТР от Microsoft уязвима с точки зрения реализации, и обладает серьезными недостатками с точки зрения протокола. Протокол аутентификации имеет известные уязвимости. Шифрование выполнено неверно, в данной реализации используется поточный шифр с обратной связью по выходу, хотя более уместен был бы блоковый шифр "шифр-блок-цепочка" (CBC). Чтобы связать слабую аутентификацию с плохим шифрованием Microsoft задала ключ шифрования как функцию от пароля пользователя вместо использования сильного алгоритма обмена ключами типа Диффи-Хеллмана или ЕКЕ. Наконец, канал управления не аутентифицируется и не сильно защищен.

Криптоанализ не подвергал сомнению протокол РРТР, но лишь реализацию протокола от Microsoft. Хотя Microsoft использует свои собственные расширения (MS-CHAP, МРРЕ, МРРС) в РРР секции РРТР, стандарт РРТР не требует этого. Производители могут включить расширения Microsoft в свои продукты по соображениям совместимости, но они не обязаны ограничиваться их использованием и, наверное, реализуют более безопасные решения. Конечно, новые расширения для корректной работы должны поддерживаться как клиентом, так и сервером.

4 Туннелирование по протоколу L2TP

Протокол L2TP (Layer 2 Tunneling Protocol – сетевой протокол туннелирования канального уровня) сочетает в себе все лучшее из протоколов PPTP и L2F (Layer 2 Forwarding – пересылка данных на канальном уровне). L2F был предложен в качестве протокола передачи для подключения по коммутируемым каналам связи. Используя его, серверы удаленного доступа инкапсулируют поступающий трафик в кадры протокола РРР, а затем передают их по каналам ГВС на сервер L2F, который, в свою очередь, удаляет упаковку пакетов и направляет их в сеть получателя.

Протокол L2TP позволяет прокладывать туннели через любые среды, где возможны пакетно-ориентированные одноранговые подключения. В их число, в частности, входят такие технологии региональных вычислительных сетей, как Х.25, Frame Relay и АТМ. Более того, в L2TP предусмотрена возможность соединения двух конечных точек несколькими туннелями.

При работе в IP-сетях протокол L2TP очень похож на PPTP. Здесь туннель прокладывается между клиентом L2TP и сервером L2TP. При этом не имеет никакого значения, подключен ли клиент к сети (например, к ЛВС) постоянно или для установления IP-подключения ему нужно сначала связаться по коммутируемому каналу с сервером сетевого доступа (так подключаются через Интернет удаленные пользователи).

Защита информации виртуальных частных сетей

Рисунок 3 – туннелирование с использованием L2TP

Как PPTP, так и L2TP прежде всего производят первичное инкапсулирование данных по протоколу РРР, а затем добавляют в полученные пакеты дополнительные заголовки, необходимые для их пересылки через промежуточные сети. На этом этапе в работе PPTP и L2TP начинают проявляться некоторые различия.

PPTP способен пересылать пакеты только через IP-сети, тогда как L2TP позволяет прокладывать туннели по любым пакетно-ориентированным средам, где возможна организация одноранговых подключений. Благодаря этому пакеты L2TP могут пересылаться по IP-сетям (с использованием протокола UDP), по частным виртуальным каналам с ретрансляцией кадров Frame Relay, по виртуальным каналам Х.25 и по виртуальным каналам АТМ.

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

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

В L2TP предусмотрена аутентификация туннеля, которой нет в PPTP. Правда, когда в туннеле используется протокол IPSec, аутентификация на канальном уровне становится ненужной, так как и L2TP, и PPTP производят ее именно по протоколу IPSec.

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

5 Протокол безопасности IP Security Protocol

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

Для обеспечения безопасности всех передач по протоколу TCP/IP с обеих сторон межсетевого устройства защиты организации в протоколе Microsoft Windows IP Security использованы принятые в качестве отраслевых стандартов алгоритмы шифрования и комплексный подход к управлению безопасностью.

Поскольку средства безопасности Windows IP Security размещены ниже транспортного уровня, администраторы сетей (и производители программного обеспечения) могут уделить внимание и направить свои усилия на придание и координацию безопасности каждой отдельной программе. Используя Windows 2000 Server, администраторы сетей обеспечивают сильную защиту для всей сети в целом, а приложения автоматически наследуют защитные меры системы безопасности Windows 2000 Server. Поддержка шифрования Windows IP Security распространяется также и на виртуальные частные сети (Virtual Private Networks – VPN).

Администраторы и менеджеры сетей выигрывают от интеграции IPSec с Windows 2000 Server по нескольким причинам, в том числе:

Открытый промышленный стандарт – IPSec обеспечивает открытый промышленный стандарт в качестве альтернативы «доморощенному» способу шифрования IP. Менеджеры сетей при этом получают выигрыш от получаемой функциональной совместимости.

Прозрачность – IPSec существует под транспортным уровнем, что делает его прозрачным для приложений и пользователей; а это означает, что при реализации IPSec в брандмауэре или маршрутизаторе нет необходимости вносить изменения в сетевые приложения настольного ПК.

Проверка прав доступа – Служба аутентификации предотвращает возможность перехвата данных при использовании неправильно объявленных данных идентификации.

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

Целостность данных – При передачах заголовки аутентификации IP и различные коды аутентификации хеш-сообщений обеспечивают целостность данных.

Динамический повторный ввод (с клавиатуры) – Динамический повторный ввод во время непрерывной связи помогает противостоять попыткам нарушения защиты.

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

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

Гибкость –Протокол Windows IP Security дает возможность распространить политику обеспечения безопасности на все предприятие или на отдельную рабочую станцию.

5.1 Разработка на основе IP Security

Протокол безопасности IP Security использует заголовок аутентификации (authentication header – AH) и инкапсулированную нагрузку безопасности (an encapsulated security payload – ESP). Заголовок AH создает конверт, обеспечивающий аутентификацию источника данных, их целостность и защиту от навязывания повторных сообщений (см. рис. 1).

Защита информации виртуальных частных сетей

Рисунок 4 - Формат заголовка AH

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

Помимо этого протокол AH обеспечивает, насколько это возможно, аутентификацию заголовков IP-пакетов, несмотря на нахождение IP-заголовков за пределами создаваемого им конверта. Аутентификация AH предотвращает манипулирование полями IP-заголовка во время прохождения пакета. По этой причине данный протокол нельзя применять в среде, где используется механизм трансляции сетевых адресов (Network Address Translation -- NAT), так как манипулирование IP-заголовками необходимо для его работы.

Протокол ESP обеспечивает конфиденциальность данных (см. рис. 2) и выполняет все функции протокола AH по защите зашифрованных неаутентифицируемых потоков данных.

Защита информации виртуальных частных сетей

Рисунок 5 - Формат заголовка ESP

Спецификация IPSec допускает работу протокола ESP без использования функций AH. В протоколе ESP можно использовать фиктивное шифрование, что эквивалентно применению протокола AH без аутентификации IP-заголовка. Это позволяет включать в работу механизм NAT, поскольку в этом случае адреса в заголовках можно модифицировать.

Протоколы ESP и AH зарегистрированы организацией IANA (Internet Address Naming Authority) и занесены в реестр протоколов под порядковыми номерами 50 и 51 соответственно. Если на пограничных маршрутизаторах уже реализованы какие-либо базовые правила фильтрации пакетов, то необходимо добавить эти два протокола к списку разрешенных протоколов. Поскольку поле "тип протокола" заголовка IP-пакета теперь будет соответствовать конверту IPSec, то первоначальный тип транспортного протокола помещается в следующее поле "тип протокола" внутри заголовка IPSec (см. рис. 3).

Защита информации виртуальных частных сетей

Рисунок 6 -Инкапсуляция протоколов

Протокол IPSec можно использовать как в транспортном, так и в туннельном режиме. В первом случае заголовок IPSec размещается между сетевым (IP) и транспортным (TCP или UDP) заголовками обычного IP-пакета. Транспортный режим разработан для применения на оконечных системах. Работа в этом режиме отражается на всех входящих в группу системах и в большинстве случаев требуется перепрограммирование приложений.

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

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

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

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

5.1.1 Полная поддержка промышленных стандартов

Windows 2000 дает возможность полностью использовать стандартные криптографические алгоритмы и методы аутентификации. Они включают следующие:

Метод Диффи-Хеллмана (Diffie-Hellman) для соглашения о совместно используемом ключе.

Код аутентификации хеш-сообщения (HMAC) и его разновидности для обеспечения целостности и защиты от несанкционированного воспроизведения.

Стандарт шифрования данных ѕЦепочка цифровых блоков для обеспечения конфиденциальности.

Метод Диффи-Хеллмана (Diffie-Hellman, DH)

Метод Диффи-Хеллмана (Diffie-Hellman, DH), названный так по именам своих изобретателей Whitfield Diffie и Martin Hellman, представляет собой алгоритм криптографии с открытым ключом, который позволяет двум обменивающимся сообщениями сторонам договариваться о совместно используемом ключе. Метод Диффи-Хеллмана начинается с обмена общедоступной информацией между двумя объектами. Затем каждый объект объединяет общедоступную информацию, полученную от другого объекта, со своей собственной секретной информацией для получения совместно используемого секретного значения.

Код аутентификации хеш-сообщения (HMAC)

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

HMAC-MD5

Дайджест-функция сообщения 95 (Message Digest function 95 – MD5) представляет собой хеш-функцию, формирующую 128-битовое значение.

HMAC-SHA

Алгоритм хеш-безопасности (Secure Hash Algorithm – SHA) представляет собой хеш-функцию, формирующую 160-битовое значение. Хотя алгоритм HMAC-SHA несколько медленнее, чем HMAC-MD5, он обеспечивает большую безопасность.

DES-CBC

Стандарт шифрования данных (Data Encryption Standard – DES) – Цепочка цифровых блоков (CBC) представляет алгоритм секретного ключа, служащий для обеспечения конфиденциальности. Для шифрования данных используется случайное число и секретный ключ. Алгоритм шифрования DES с явно заданным вектором инициализации (Initialization Vector - IV) применяют в протоколе ESP по умолчанию. Он необходим для обеспечения IPSec-совместимости. В качестве альтернативы DES определены следующие алгоритмы: Triple DES, CAST-128, RC5, IDEA, Blowfish и ARCFour.

Многие пользователи считают алгоритм CAST (стандарт RFC 2144) таким же стойким, как алгоритм Triple DES с 128-битовым ключом. Кроме того, он быстрее чем DES. RC5 (стандарт RFC 2040) - алгоритм шифрования потока данных, использующий ключ переменной длины. Стойкость RC5 зависит от длины ключа, которая может достигать 256 бит. Алгоритм IDEA (International Data Encryption Algorithm) рассматривается как "быстрый" эквивалент Triple DES. Еще одним алгоритмом, использующим ключ переменной длины, является Blowfish. Это тоже "крепкий орешек", над которым долгое время будут трудиться злоумышленники. Последний алгоритм, ARCFour, является общедоступной версией алгоритма RC4.

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

5.1.2 Поддерживаемые стандарты и ссылки

Все протоколы, опубликованные группой IETF, полностью поддерживаются и используются Windows 2000. Они реализуются согласно последним предварительным сообщениям IEFT, предложенным рабочей группой IPSec, которые, дополнительно к предварительным документам ISAKMP/Oakley, включают документы по общей архитектуре и документы, определяющие форматы заголовка и преобразований.

Система безопасности IP Windows 2000 реализует протокол Ассоциации безопасности Интернета и управления ключами (Internet Security Association/Key Management Protocol – ISAKMP), используя протокол определения ключа Oakley, который допускает динамическое повторное использование ключа.

Протоколы безопасности выполняют различные сервисные действия для обеспечения безопасных передач в сети. В Windows 2000 используются следующие протоколы безопасности:

Протокол Ассоциации безопасности Internet и управления ключами (Internet Security Association / Key Management Protocol)

Протокол определения ключа Oakley

Заголовок аутентификации IP

Протокол инкапсулированной безопасности IP

Протокол ISAKMP/Oakley

Задание алгоритмов IPSec - дело непростое, для этого требуется протокол управления сеансом. Протокол ISAKMP (Internet Security Association Key Management Protocol) является рамочной основой для такого протокола, а протокол Oakley -- это уже конкретная реализация его на этой основе, предназначенная для совместного использования с IPSec.

Протокол Oakley имеет более широкий набор функциональных возможностей, чем необходимо для управления IPSec-сеансами. Реализация ISAKMP/Oakley представляет собой функциональное подмножество, достаточное, чтобы обеспечить безопасный способ сообщения аутентификационных данных для генерации ключей и SA-параметров. Обмен по протоколу ISAKMP/Oakley происходит в двух режимах (фазах): основном и быстром. В соответствии с протоколом Oakley, обмен начинается в основном и продолжается в быстром режиме. В первом режиме устанавливаются соглашения SA для обмена данными по протоколу Oakley, а во втором - по протоколу IPSec.

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

Обмен ключами в основном режиме осуществляется по методу Диффи-Хелмана (D-H), который требует интенсивного использования вычислительных ресурсов. Этот метод является механизмом распределения открытых ключей для безопасного обмена секретной информацией без применения какой-либо информации, заранее известной обеим сторонам. Поэтому им активно пользуются для установления безопасных сеансов связи в тех случаях, когда необходима динамическая защита и когда оконечные системы не принадлежат одной и той же системе административного управления. Например, метод D-H можно использовать в электронной коммерции при установлении соединения для передачи транзакций между двумя компаниями.

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

В основном режиме оба участника обмена устанавливают SA-соглашения для безопасного общения друг с другом по протоколу Oakley. В быстром режиме SA-соглашения устанавливаются уже "от лица" протокола IPSec или любой другой службы, которой необходимы данные для генерации ключей или согласования параметров.

Протокол ISAKMP/Oakley не был специально разработан для совместного использования с протоколом IPSec, поэтому возникает необходимость в так называемой области интерпретации (Domain Of Interpretation - DOI), которая обеспечила бы совместную работу протоколов IPSec и ISAKMP/Oakley. Чтобы другие протоколы также могли использовать ISAKMP/Oakley, они должны иметь собственные DOI-области. В настоящий момент таких областей для других протоколов не существует, но ситуация может измениться на очередной конференции группы IETF или в том случае, если частный разработчик, например фирма Netscape, решит использовать этот механизм.

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

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

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

Согласно этим срокам определяется, как скоро, в зависимости от времени или объема переданных данных, потребуется новое согласование в быстром режиме. Есть два разных срока существования SA-соглашения. Основной режим задает его для протокола Oakley, а быстрый - для обмена по протоколу IPSec.

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

5.2 Туннелирование с применением IPSec

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

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

IPSec предназначен не для клиент-серверного туннелирования, а для защиты туннелей между серверами и маршрутизаторами. Таким образом, он не заменяет протоколы PPTP и L2TP, а дополняет их. Совместное применение позволяет сочетать гибкость протоколов ВЧС канального уровня (PPTP и L2TP) с высочайшим уровнем безопасности, который обеспечивает IPSec.

IPSec описывает не только механизмы шифрования IP-трафика, но и формат IP-пакетов, передаваемых по IP-туннелям. Режим такой передачи обычно называют туннельным режимом IPSec (IPSec Tunnel Mode). Туннель IPSec состоит из туннельного клиента и туннельного сервера, которые настроены на применение протокола IPSec, и механизма шифрования по согласованию (negotiated encryption mechanism).

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

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

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

Для аутентификации источника и проверки целостности нешифрованной информации протокол IPSec использует заголовок аутентификации и порядковый номер пакета. В случае шифрования трафика IPSec обращается к помощи протокола шифрования дейтаграмм ESP (Encapsulating Security Payload - безопасное закрытие содержания). Применение IPSec предполагает, что секретный ключ известен только отправителю и получателю сообщения. Таким образом, если данные аутентификации оказываются истинными, получатель делает вывод, что они поступили от отправителя и не подверглись изменению в процессе пересылки.

5.3 Пример передачи данных по протоколу IPSec

Пример иллюстрирует передачу данных от пользователя хост-компьютера A к пользователю компьютера B. В обоих компьютерах реализована безопасность Windows IP Security.

Защита информации виртуальных частных сетей

Рисунок 7 – передача данных по IPSec

Directory Service – Служба каталога

IP Security Policy – Политика безопасности IP

Policy Agent – Агент безопасности

ISAKMP/Oakley Service – Служба ISAKMP/Oakley

SA Negotiation Key Exchange – Обмен ключами при безопасных переговорах

Application – Приложение

Transport Layer TCP/UDP – Транспортный уровень TCP/UDP

Internet Layer – Уровень Интернета

Encrypted IP packets – Зашифрованные IP-пакеты

На пользовательском уровне процесс «засекречивания» IP-пакетов совершенно прозрачен. Пользователь 1 запускает приложение, использующее протокол TCP/IP, например, FTP, и пересылает данные пользователю 2.

Политика безопасности, назначенная администратором для компьютеров А и В, определяет уровень безопасности передачи информации между ними. Эти уровни воспринимаются агентом политики и передаются службе ISAKMP/Oakley и драйверу IPSEC. Для установления ключа и общего метода переговоров (безопасное соединение) служба ISAKMP/Oakley каждого компьютера использует политику переговоров, связанную с приписанной политикой безопасности. Результаты политики переговоров ISAKMP между двумя компьютерами передаются драйверу IPSEC, использующему ключ для шифрования данных. Наконец, драйвер IPSEC посылает зашифрованные данные в компьютер B. Драйвер IPSEC компьютера B расшифровывает переданные данные и направляет их принимающей программе.

5.4 Преимущества и недостатки протокола L2TP/IPSec.

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

К недостаткам можно отнести то, что схема L2TP over IPSec создает проблемы для пользователей, так как два протокола поддерживать сложнее, чем один. Кроме того, алгоритмам, заложенным в предварительном варианте спецификаций, недостает эффективности, поскольку идентификация пользователя на другом конце соединения производится уже после того, как соединение установлено. А если пользователь не прошел авторизацию на доступ к предоставляемым услугам, соединение будет разорвано. Применение протоколов Internet Key Exchange (IKE) с заранее согласованными ключами требует статических IP-адресов, а это не позволяет работать по коммутируемым телефонным линиям. Определенные в рамках IPSec процедуры IKE предназначены для согласования параметров защищенной передачи, включая используемый в ходе сеанса алгоритм шифрования данных, между участниками сеанса связи. Очевидно, применение статических адресов и заранее согласованных ключей устроит далеко не всех пользователей. Тем из них, кто работает через обычные аналоговые модемы, присваиваются динамические IP-адреса, а партнеры и клиенты компании, получающие доступ в корпоративную экстрасеть, не могут заранее знать, какие ключи будут применяться для обеспечения информационной безопасности.

6 Сравнение протоколов PPTP и IPSec.

Point-to-Point Tunneling Protocol (PPTP) и протокол IP Security (IPSec) допускают организацию частных сеансов связи поверх Internet и связывают удаленных пользователей и корпоративные сети защищенными каналами. Каждый протокол имеет свои достоинства и недостатки, касающиеся безопасности данных и удобства развертывания.

Безопасность PPTP против безопасности IPSec

PPTP, разработанный и популяризируемый компаниями Microsoft и U.S. Robotics, в первую очередь предназначен для виртуальных частных сетей, основанных на коммутируемых соединениях. Протокол призван активизировать использование удаленного доступа, давая возможность пользователям устанавливать коммутируемые соединения с Internet-провайдерами и создавать защищенный туннель к своим корпоративным сетям. В отличие от IPSec протокол PPTP изначально не предназначался для организации туннелей между локальными сетями. PPTP расширяет возможности PPP — протокола, который специфицирует соединения типа точка-точка в IP-сетях. PPP широко используется для организации доступа пользователей в общедоступную сеть Internet и частные корпоративные сети по коммутируемым или широкополосным соединениям. Поскольку PPP функционирует на уровне 2, соединение PPTP, которое инкапсулирует пакеты PPP, позволяет передавать не только IP-пакеты, но и IPX или NetBEUI. Со своей стороны, IPSec функционирует на уровне 3 и способен обеспечивать туннелированную транспортировку IP-пакетов.

Метод шифрования, стандартным образом применяемый в PPTP, специфицируется на уровне PPP. Обычно в качестве клиента PPP выступает настольный компьютер с операционной системой Microsoft, а в качестве протокола шифрования используется Microsoft Point-to-Point Encryption (MРPE). Данный протокол основывается на стандарте RSA RC4 и поддерживает 40- или 128-разрядное шифрование. Для многих приложений такого уровня шифрования вполне достаточно, хотя он и считается менее надежным, нежели ряд других алгоритмов шифрования, предлагаемых IPSec, в частности, 168-разрядный Triple-Data Encryption Standard (DES).

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

IPSec также поддерживает соединения между удаленными пользователями и корпоративными сетями. Аналогичным образом, Microsoft добавляет поддержку туннелирования между локальными сетями для протокола PPTP в своем Routing and Remote Access Server для операционной системы Windows NT Server 4.0.

Что касается надежности шифрования и обеспечения целостности данных, то IPSec — вне конкуренции. Протокол сочетает в себе управление ключами с поддержкой сертификатов стандарта X.509, целостности и защиты информации.

Более того, 168-разрядный алгоритм Triple-DES — самый надежный вид шифрования, предлагаемый в IPSec, — обеспечивает более высокий уровень защиты, нежели 128-разрядный алгоритм RC4. Кроме того, IPSec позволяет выполнять шифрование и аутентификацию отдельных пакетов, а также предупредить так называемую «атаку посредника», при которой данные перехватываются третьей стороной, модифицируются и передаются получателю.

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

Многим предприятиям доступность PPTP на платформе Windows (протокол поддерживает Windows NT, 95 и 98) помогает без особых проблем развертывать и поддерживать виртуальные частные сети. Другие же полагают, что PPTP обеспечивает менее надежную защиту, чем IPSec.

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

7 Протокол EAP

Протокол EAP (Extensible Authentication Protocol – расширяемый протокол аутентификации) представляет собой расширение для протокола РРР. Он содержит стандартный механизм поддержки ряда методов аутентификации, включая жетоны, протокол Kerberos, открытые ключи и секретные ключи S/Key. Этот механизм полностью поддерживается как серверами удаленного доступа Windows NT Dial-Up Server, так и сетевыми клиентами удаленного доступа Dial-Up Networking Client. Протокол EAP является крайне важным компонентом безопасных ВЧС, обеспечивающим защиту от силовых атак, подбора пароля по словарю и попыток угадать его.

Применение EAP расширяет возможности ВЧС на базе сервера удаленного доступа Windows NT Remote Access Service, позволяя производить аутентификацию с помощью модулей независимых производителей. Реализация этого протокола в среде Windows NT стала ответом Microsoft на многочисленные просьбы пользователей, которые не хотят отказываться от привычных аппаратных средств безопасности.

Протокол EAP был предложен Целевой группой технической поддержки Интернета в качестве расширения для протокола РРР. Он содержит дополнительные механизмы аутентификации, необходимые для проверки РРР-соединений. Главная задача EAP состоит в динамическом подключении модулей аутентификации на обеих – клиентской и серверной – сторонах такого соединения. Этот протокол отличается очень высокой гибкостью, обеспечивая уникальность и вариативность аутентификации. Практическая реализация EAP включена в Microsoft Windows 2000.

7.1 Обеспечение безопасности на уровне транзакций

Очень высокий уровень безопасности ВЧС обеспечивается за счет применения микропроцессорных карточек и жетонов аутентификации. Микропроцессорные карточки представляют собой миниатюрные устройства размером с кредитную карточку со встроенными в них ЦПУ и небольшим объемом оперативной памяти. Сюда обычно заносятся данные, удостоверяющие личность пользователя (например, сертификаты открытого ключа), ключи шифрования и параметры учетной записи. Некоторые из микропроцессорных карточек содержат также алгоритм шифрования, благодаря которому криптоключи никогда не передаются вовне. В системах обеспечения безопасности удаленного доступа микропроцессорные карточки сегодня используются довольно редко, так как их поддерживают лишь немногие пакеты такого типа. Ситуация должна измениться с появлением Windows 2000. Эта операционная система позволит применять такие карточки при самых различных видах аутентификации, включая RAS, L2TP и PPTP.

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

Поддержку жетонов аутентификации, как и пользовательских сертификатов с открытым ключом, обеспечит синтетический протокол EAP-TLS (Extended Authentication Protocol-Transaction Layer Security – расширяемый протокол аутентификации и обеспечение безопасности на уровне транзакций). Он уже представлен на рассмотрение Целевой группы технической поддержки Интернета в качестве проекта спецификации на метод аутентификации повышенной надежности с применением сертификатов открытого ключа. При работе по схеме EAP-TLS клиент посылает на сервер удаленного доступа пользовательский сертификат, а в ответ получает с него серверный сертификат. Первый из них обеспечивает надежную аутентификацию пользователя на сервере, а второй гарантирует, что клиент вступил в контакт именно с тем сервером, который ему нужен. При проверке достоверности полученных данных оба участника такого обмена полагаются на цепочку доверенных органов сертификации.

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

EAP-TLS представляет собой, по сути, разновидность протокола EAP, реализованную в Windows 2000. Как и MS-CHAP, он служит для получения криптоключа, который используется протоколом MPPE для шифрования всех последующих данных.

7.2 Аутентификация с помощью службы RADIUS

RADIUS (Remote Authentication Dial-in User Service – служба дистанционной аутентификации пользователей по коммутируемым линиям) представляет собой центральный сервер с базой данных аутентификации и служит дополнением к другим протоколам аутентификации запросов. В основу этой службы положены протокол UDP, обслуживающий протоколы РРР, РАР и CHAP, а также функция входа в системы Unix и ряд других механизмов аутентификации. Кроме своего непосредственного предназначения служба RADIUS позволяет также производить учет бюджета ВЧС.

Получив от сетевой службы аутентификации NAS запрос на подключение пользователя, сервер RADIUS сравнивает полученные данные с информацией из своей базы данных. Здесь же находится и центральное хранилище параметров подключений для всех зарегистрированных пользователей. При необходимости сервер не ограничивается простым ответом на запрос (ДА/НЕТ), а сообщает в NAS ряд сведений относительно конкретного пользователя. В частности, он может указать наибольшее время сеанса, выделенный статический IP-адрес и информацию, позволяющую произвести обратный вызов пользователя.

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

7.3 Учет бюджета ВЧС с помощью службы RADIUS

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

7.4 Протокол EAP и RADIUS

Чтобы совместно использовать протокол EAP с сервером RADIUS, необходимо внести коррективы как в службу NAS, так и в службу RADIUS. При традиционной схеме аутентификации эти службы производят одну-единственную транзакцию, состоящую из запроса и ответа на него. Однако при аутентификации по протоколу EAP служба NAS не может самостоятельно собрать информацию о клиенте, необходимую для аутентификации на сервере RADIUS. Для решения этой проблемы системный администратор может настроить службу NAS таким образом, что она будет направлять клиенту идентификатор, включив его в сообщение EAP. Тот в ответ сообщит службе сетевой аутентификации данные об имени пользователя и домене. Служба NAS включает их в запрос EAP-start и в таком виде направляет на сервер RADIUS. Дальнейший процесс аутентификации производится, как обычно: служба RADIUS передает клиенту через службу NAS сообщения EAP и отвечает на них до тех пор, пока аутентификация не даст положительного (или отрицательного) результата.

8 Шифрование

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

Протоколы PPTP и L2TP, как и лежащий в их основе РРР, допускают применение дополнительных протоколов шифрования и сжатия. В частности, для повышения защищенности данных здесь может использоваться протокол IPSec, который поддерживается в реализации L2TP, выполненной Microsoft. При необходимости безопасность информации в ВЧС можно обеспечить и с помощью других криптотехнологий.

8.1 Симметричное шифрование (с личным ключом)

В основу симметричного шифрования (его также называют шифрованием с личным ключом или обычным шифрованием) положен секретный ключ, известный только участникам сеанса связи. Отправитель обрабатывает свое сообщение по специальному математическому алгоритму с использованием секретного ключа, преобразуя тем самым его открытый текст в шифрованный. Получатель сообщения с помощью того же самого секретного ключа проводит обратную операцию, после чего получает исходный открытый текст. Примером схемы симметричного шифрования могут служить алгоритмы RSA RC4 (применяемый в протоколе MPPE), DES (Data Encryption Standard – стандарт шифрования данных), IDEA (International Data Encryption Algorithm – международный алгоритм шифрования данных), а также технология шифрования Skipjack, предложенная правительством США для микросхемы Clipper.

8.2 Асимметричное шифрование (с открытым ключом)

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

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

8.3 Структурное и бесструктурное шифрование

Для правильного выбора схемы шифрования очень важно понять различия между структурным (stateful) и бесструктурным (stateless) шифрованием.

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

Чтобы правильно выбрать тип шифрования, необходимо найти компромиссное решение, сбалансировав стойкость шифрования и производительности криптосистемы в средах с высоким уровнем потерь (или в сетях, где нарушается последовательность доставки пакетов). Бесструктурное шифрование позволяет дешифровать каждый пакет автономно, без какой-либо связи с предыдущими. По стойкости такой подход уступает структурному шифрованию, где не получив предыдущего пакета, невозможно расшифровать последующий. Однако в последнем случае достаточно одному-единственному пакету затеряться в сети – и дешифрование всех пакетов, следующих за ним, станет невозможным. Это может привести к серьезному снижению производительности в сетях, где велика вероятность потери пакетов или нарушения порядка их доставки.

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

8.4 IPSec и бесструктурное шифрование

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

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

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

9 Фильтрация

Фильтрация служит еще одним мощным средством обеспечения сетевой безопасности. Опираясь на нее, администратор может разрешить доступ к корпоративной сети из Интернета только тем пользователям, которые прошли аутентификацию в ВЧС. К тому же, отсеивание пакетов, не относящихся к протоколам PPTP и L2TP, снижает риск атаки на корпоративную сеть через сервер шлюза ВЧС. Пропуская поступающий трафик через фильтр, можно удалить из него все пакеты, не отвечающие заданным критериям (протоколам). В комбинации с шифрованием по протоколу РРР эта функция гарантирует, что поступить в частную ЛВС и покинуть ее смогут только санкционированные шифрованные данные.

9.1 Фильтрация на сервере маршрутизации и удаленного доступа ВЧС

Сервер R/RAS (Routing and Remote Access Server – сервер маршрутизации и удаленного доступа) не только производит маршрутизацию сообщений, но и выполняет целый ряд других функций. Так, он способен обслуживать удаленный доступ по коммутируемым каналам, поддерживает ВЧС, обеспечивает фильтрацию пакетов на отдельных портах. А в среде Windows 2000 этот сервер сможет работать с протоколом L2TP.

Разработчики сервера ВЧС R/RAS предусмотрели возможность установки фильтров PPTP и L2TP на входных портах туннельного сервера. Такая схема позволяет блокировать все пакеты, не соответствующие критериям протоколов, которые установлены на сервере. В частности, в сеть могут пропускаться лишь пакеты, адресованные конкретному серверу, или те, исходные адреса которых указаны в список разрешенных IP-адресов отправителей. Может также проводиться проверка подлинности адресов в частной сети отправителя и получателя, назначаемых туннельным сервером.

Допускается и фильтрация трафика на выходных портах туннельного сервера, которая отсеивает данные, исходящие из частной сети. Здесь, например, можно наладить проверку адресов получателей и их сопоставление со списком разрешенных, который ведется на сервере R/RAS. Точно так же можно производить проверку адресов отправителей пакетов.

9.2 Фильтрация IPSec

Протокол IPSec можно представить как еще один уровень, лежащий ниже стека TCP/IP. Управление этим уровнем производится в соответствии с политикой безопасности на каждом компьютере, учитываются и правила обеспечения безопасности, согласованные отправителем и получателем сообщения. Политика безопасности определяет как используемый набор фильтров, так и ассоциированные функции безопасности (associated security behaviors). Если IP-адрес, протокол и номер порта, указанные в пакете, соответствуют критериям фильтрации, следующим этапом становится проверка ассоциированных функций безопасности.

9.3 ВЧС и брандмауэры

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

Туннельный сервер ВЧС может быть установлен перед брандмауэром, позади него или на одном компьютере с ним. Наиболее высокий уровень защиты достигается при установке сервера перед брандмауэром. В среде Windows NT туннель ВЧС настраивается таким образом, что в сеть проходят только пакеты PPTP. Пройдя фильтрацию, они разуплотняются, дешифруются и в таком виде поступают на брандмауэр, где их содержимое вновь подвергается фильтрации и анализу. Именно такая схема – установка сервера ВЧС перед брандмауэром – рекомендуется для применения в расширенных интрасетях, используемых многочисленными доверенными партнерами, и для защиты финансовых ресурсов. Впрочем, такой совет не универсален, окончательное решение следует принимать в каждом конкретном случае отдельно.

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

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

10 Выбор средств ВЧС

Абсолютная безопасность недостижима. Но точно так же нельзя полагать, будто существует абсолютная угроза безопасности. Виртуальные частные сети Microsoft на базе протокола PPTP с применением MPPE-шифрования обеспечивают весьма надежную защиту.

Заложенная в Windows 2000 поддержка протокола L2TP, полная защита канала связи по протоколу IPSec, применение протокола EAP в микропроцессорных карточках, сертификаты Kerberos – все это предоставляет сетевым администраторам богатейший выбор средств обеспечения безопасности, разработанных корпорацией Microsoft и рекомендуемых ею для развертывания виртуальных частных сетей.

10.1 Анализ угроз сетевой безопасности

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

В ходе анализа следует также учесть, что может понадобиться для внедрения той или иной системы. Скажем, развертывание полномасштабной инфраструктуры шифрования IP Security может потребовать замены всех компьютеров с процессорами 486 и ранних Pentium, которые не способны удовлетворить требования к производительности ЦПУ. А ведь применение IPSec может стать насущной необходимостью, если на серверах сети размещается конфиденциальная информация и высока вероятность попыток их взлома. В таких условиях капиталовложения в развертывание новой инфраструктуры будут вполне оправданными. Те же организации, которые особого интереса для хакеров и конкурентов не представляют, могут вполне ограничиться ВЧС на базе PPTP, не тратясь на модернизацию оборудования.

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

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

10.2 Безопасность и требования к паролю

Простота развертывания и управления, дополненная высочайшим уровнем безопасности и шифрованием данных по протоколу MPPE, – вот что делает виртуальные частные сети Microsoft на базе протокола PPTP одной из самых популярных сетевых сред. Конечно, каждому администратору приходится самостоятельно искать и находить именно ту систему, которая в наибольшей степени отвечает требованиям, выработанным в ходе анализа угроз сетевой безопасности. Однако большинство организаций, включая саму Microsoft, уже убедились в том, что ВЧС на базе PPTP обеспечивают высочайший уровень защиты информации и вполне подходят большинству компаний.

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

применение только паролей Windows NT;

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

регулярную смену пароля.

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

10.3 Возможности реализаций VPN на различных версиях Windows.

	Windows 9x	Windows NT	Windows 2000
Работа в качестве клиента ВЧС	+	+	+
Работа в качестве сервера ВЧС	-	+	+
Поддержка протокола PPTP	+	+	+
Поддержка протокола L2TP	-	-	+
Необходимость дополнительной установки протоколов для работы с ВЧС	+	+	-

10.4 Часто задаваемые вопросы при выборе средств VPN

Есть ли различия в обеспечении безопасности удаленного доступа и доступа в ВЧС?

Конечно. Так, в виртуальных частных сетях ощущается гораздо большая потребность в шифровании. Здесь трафик проходит через Интернет, где вероятность его перехвата гораздо выше, чем в телефонных каналах. Чтобы подслушать телефонный разговор, достаточно получить физический доступ к кабелю или коммутатору телефонной компании. Конечно, бывает и так, хотя злоумышленнику приходится преодолевать значительные трудности. В Интернете же путь от PPTP-клиента к PPTP-серверу пролегает через множество промежуточных устройств (коммутаторов, серверов имен и так далее). А чем больше промежуточных звеньев, тем легче злоумышленнику проникнуть в одно из них, чтобы перехватить трафик данных или перенаправить его.

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

Можно ли сказать, что ВЧС на базе IPSec безопаснее виртуальных сетей на базе PPTP?

Не обязательно. Какой бы протокол ни применялся, безопасность ВЧС на его базе зависит от многих аспектов практической реализации сетевых компонентов. Большинство современных реализаций IPSec поддерживают сертификаты открытого ключа и, теоретически, способны генерировать более стойкие ключи, чем механизмы на базе общих паролей. Однако почти все они полагаются исключительно на машинные сертификаты и, следовательно, не производят аутентификацию пользователя. То есть, доступ здесь предоставляется не пользователю, а машине, – кто же работает за ней в данный момент, никому не известно. Стандартное требование для доступа в ВЧС – обязательная проверка полномочий. Если сопоставить все эти положения, то становится ясно: в тех случаях, когда клиентский компьютер доступен более, чем одному пользователю, одних машинных сертификатов для управления доступом недостаточно – это создает брешь в системе обеспечения безопасности.

Можно ли сказать, что ВЧС на базе L2TP безопаснее виртуальных сетей на базе PPTP?

Тоже не обязательно. Как и в случае с другими средствами создания ВЧС, безопасность сетей на базе L2TP во многом определяется особенностями их практической реализации. Безопасность стандартных ВЧС такого типа достигается за счет применения протокола IPSec, который обеспечивает конфиденциальность и одновременно контролирует целостность сообщений. При этом, как правило, одновременно используется и аутентификация по протоколу РРР, которая позволяет проверить, кто именно подключается к сети. Следовательно ВЧС на базе L2TP с применением IPSec способны обеспечить надежную защиту информации в самых разных условиях.

Можно ли сказать, что межсерверные ВЧС безопаснее клиент-серверных виртуальных сетей?

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

11 Создание виртуального частного подключения в Windows 2000

11.1 Создание подключения к удаленному серверу

В «Панели управления» открываем папку «Сеть и удаленный доступ к сети».

Нажимаем на «Создание нового подключения». Появляется следующее окошко:

Защита информации виртуальных частных сетей

Рисунок 8

Нажимаем кнопку «Далее».

Видим:

Защита информации виртуальных частных сетей

Рисунок 9

Выбираем «Подключение к виртуальной частной сети через Интернет» и нажимаем «Далее».

Опять вылезает окно следующего содержания:

Защита информации виртуальных частных сетей

Рисунок 10

Здесь мы вводим IP-адрес сервера, с которым мы хотим установить VPN-соединение, «Далее».

Следующее окно:

Защита информации виртуальных частных сетей

Рисунок 11

Здесь я выбрал «только для меня» (так захотелось), «Далее».

Следующее окно:

Защита информации виртуальных частных сетей

Рисунок 12

Здесь мы вводим название подключения, «Готово».

Итак, в окне «Сеть и удалённый доступ к сети» появился значок с названием подключения, давайте посмотрим:

Защита информации виртуальных частных сетей

Рисунок 13

Что же теперь? А теперь мы легко устанавливаем VPN-соединение, нажав на вышеописанный значок:

Защита информации виртуальных частных сетей

Рисунок 14

Здесь мы вводим имя и пароль. Посмотрим, что произойдёт дальше!

А дальше происходит следующее:

Защита информации виртуальных частных сетей

Рисунок 15

Защита информации виртуальных частных сетей

Рисунок 16

Защита информации виртуальных частных сетей

Рисунок 17

Ну, конечно, случаются некоторые неприятности:

Защита информации виртуальных частных сетей

Рисунок 18

Примем это как есть. И вот награда за столь трудоёмкие затраты энергии:

Защита информации виртуальных частных сетей

Рисунок 19

После этого на панели задач справа появляется значок «Состояние подключения». Интересно, а что же там? А там вот что:

Защита информации виртуальных частных сетей

Рисунок 20

Посмотрим закладку «Сведения»:

Защита информации виртуальных частных сетей

Рисунок 21

11.2 Создание входящего подключения

Теперь нам необходимо настроить Windows2000 на приём VPN-подключений.

Опять нажимаем «Создание нового подключения», «Далее» и выбираем «Принимать входящие подключения»:

Защита информации виртуальных частных сетей

Рисунок 22

Естественно, нажимаем «Далее».

Вот что появляется дальше:

Защита информации виртуальных частных сетей

Рисунок 23

Здесь всё понятно, «Далее».

На данном этапе и определяется возможность VPN-подключения к вашему компьютеру:

Защита информации виртуальных частных сетей

Рисунок 24

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

Защита информации виртуальных частных сетей

Рисунок 25

Теперь выбираем используемые сетевые компоненты для подключения:

Защита информации виртуальных частных сетей

Рисунок 26

Далее мастер сетевого подключения предложит название соединения. Оставим его: «Входящие подключения».

Теперь посмотрим на свойства VPN-подключения. Для этого в окне «Сеть и удалённый доступ к сети» наведём на значок нашего соединения «В этом и заключается моя курсовая работа», нажмём правую кнопку мыши и выберем «Свойства».

Закладка «Общие». Здесь можно указать IP-адрес компьютера, с которым мы будем устанавливать VPN-соединение, а так же указать номер телефона:

Защита информации виртуальных частных сетей

Рисунок 27

Закладка «Параметры». Здесь указываются Параметры набора номера и Параметры повторного звонка:

Защита информации виртуальных частных сетей

Рисунок 28

Закладка «Безопасность». Здесь у нас имеется два пункта «Параметров безопасности»: «Обычные» и Дополнительные».

Защита информации виртуальных частных сетей

Рисунок 29

В меню «При проверке используется:» можно выбрать либо «Безопасный пароль», либо «Смарт-карта».

Если выбрать пункт «Дополнительные» и нажать «Настройка», то вылезет следующее окно:

Защита информации виртуальных частных сетей

Рисунок 30

В меню «Шифрование данных» можно выбрать три пункта:

обязательное (отключиться если нет шифрования)

необязательное (подключиться даже без шифрования)

неразрешено (отключиться если требуется шифрование)

В меню «Безопасный вход» имеется два пункта:

Протокол расширенной проверки подлинности. Здесь имеется список методов проверки подлинности, доступных на компьютере.

Разрешить следующие протоколы. Здесь указывается, какие протоколы разрешить/не разрешить.

Закладка «Сеть». Здесь можно выбрать тип вызываемого сервера VPN: Автоматически, Туннельный протокол точка-точка (PPTP) и туннельный протокол второго уровня (L2TP). Так же имеется список доступных для использования сетевых компонентов.

Защита информации виртуальных частных сетей

Рисунок 31

Закладка «Общий доступ».

Защита информации виртуальных частных сетей

Рисунок 32

Если навести на «Общий доступ» и нажать правую кнопку мыши, то появится следующая подсказка:

Защита информации виртуальных частных сетей

Рисунок 33

12 Создание виртуального частного подключения в Windows NT

12.1 Установка протокола PPTP

Установка протокола PPTP (в нашем случае он уже установлен). В «Панели управления» дважды щелкаем на папку «Сеть». Затем смотрим закладку «Протоколы»:

Защита информации виртуальных частных сетей

Рисунок 34

Нажимаем на кнопку “Add” (Добавить), выбираем Point to Point Tunneling Protocol, нажимаем ОК:

Защита информации виртуальных частных сетей

Рисунок 35

Чтобы посмотреть конфигурацию PPTP, нужно нажать правой кнопкой на Point to Point Tunneling Protocol:

Защита информации виртуальных частных сетей

Рисунок 36

Здесь можно выбрать количество одновременных подключений к серверу.

12.2 Добавление VPN устройств на PPTP сервер

Наводим курсор на Remote Access Service и нажимаем Properties.

Защита информации виртуальных частных сетей

Рисунок 37

Затем для добавления VPN-устройства нужно нажать Add и выбрать VPN-устройство:

Защита информации виртуальных частных сетей

Рисунок 38

Устройство добавлено:

Защита информации виртуальных частных сетей

Рисунок 39

Для конфигурирования VPN-устройства нажимаем Configure:

Защита информации виртуальных частных сетей

Рисунок 40

Здесь имеются следующие возможности:

Только исходящие звонки

Только входящие звонки

Исходящие и входящие звонки

Выбираем «исходящие и входящие звонки». Теперь сервер может принимать и создавать VPN-соединения.

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

для соединения с Интернет-провайдером

для соединения с PPTP сервером

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

12.3 Создание записи в телефонной книге для подключения к провайдеру Интернета

Запускаем программу Dial-Up Networking (Start, Accessories). В появившемся окне вводим имя новой записи и нажимаем «Next». Во вновь появившемся окне выбираем I am calling the Internet и нажимаем «Next»:

Защита информации виртуальных частных сетей

Рисунок 41

В следующем окне выбираем модем, нажимаем «Next». Далее появляется окно, в котором мы вводим телефонный номер провайдера, нажимаем «Next». Новая запись сделана. Можно редактировать запись нажав «More», «Edit entry and modem properties». Появиться окно с открытой закладкой «Basic»:

Защита информации виртуальных частных сетей

Рисунок 42

Здесь можно ввести имя записи, другой номер телефона и т.д.

Закладка «Server». Здесь можно выбрать тип сервера, используемые протоколы, установить сжатие данных:

Защита информации виртуальных частных сетей

Рисунок 43

Закладка «Security». Здесь выбирается политика шифрования и аутентификации:

Защита информации виртуальных частных сетей

Рисунок 44

12.4 Создание записи в телефонной книге для подключения к PPTP серверу

Здесь необходимо произвести операции, описанные выше, за исключением следующих:

в окне выбора модема нужно выбрать устройство RASPPTPM(VPN1), нажать «Next»

в появившемся окне вместо телефонного номера ввести IP-адрес сервера

Появилась новая запись:

Защита информации виртуальных частных сетей

Рисунок 45

Для редактирования записи нужно нажать «More», «Edit entry and modem properties»:

Защита информации виртуальных частных сетей

Рисунок 46

Теперь можно подключиться к PPTP серверу. В окне Dial-Up Networking выбираем запись для подключения к PPTP серверу и нажимаем «Dial». После проверки имени и пароля появляется окно:

Защита информации виртуальных частных сетей

Рисунок 47

Соединение произведено успешно.

В правом углу «Панели задач» появляется значок Dial-Up Networking Monitor. Если щёлкнуть на него, появиться окно:

Защита информации виртуальных частных сетей

Рисунок 48

13 Создание виртуального частного подключения в Windows 9х

Microsoft Windows 9x имеет весьма скромные возможности для создания VPN-соединений по сравнению c Windows NT и тем более с Windows 2000. Здесь можно работать только в качестве PPTP клиента.

13.1 Установка Адаптера виртуальной частной сети Microsoft

Сначала необходимо установить адаптер виртуальной частной сети Microsoft. В «Панели управления» дважды щелкаем на папку «Сеть». Затем нажимаем кнопку «Добавить», выбираем тип устанавливаемого устройства – Сетевая плата и снова нажимаем «Добавить». В появившемся окне выбираем Изготовитель: Microsoft, Сетевая плата: Адаптер виртуальной частной сети Microsoft. Так же необходимо установить «Контроллер удалённого доступа»:

Защита информации виртуальных частных сетей

Рисунок 49

После проделанных операций закладка «Конфигурация» папки «Сеть» будет иметь следующий вид:

Защита информации виртуальных частных сетей

Рисунок 50

13.2 Создание VPN-соединения

1. Теперь можно приступить к созданию VPN-соединения. Для этого в папке «Удаленный доступ к сети» дважды щелкаем на значок «Новое соединение». Появляется следующее окно:

Защита информации виртуальных частных сетей

Рисунок 51

Здесь вводим название соединения, выбираем Microsoft VPN Adapter и нажимаем «Далее».

Во вновь появившемся окне вводим IP-адрес VPN-сервера:

Защита информации виртуальных частных сетей

Рисунок 52

В папке «Удаленный доступ к сети» появляется значок с названием соединения:

Защита информации виртуальных частных сетей

Рисунок 53

Дважды щёлкаем на значок с нашим VPN-соединением. В появившемся окне вводим имя и пароль и нажимаем «Подключиться»:

Защита информации виртуальных частных сетей

Рисунок 54

Далее происходит следующее:

Защита информации виртуальных частных сетей

Рисунок 55

7. Соединение произведено успешно:

Защита информации виртуальных частных сетей

Рисунок 56

14 Использование программы Sniffer Pro для просмотра содержимого пакетов

Для того чтобы просмотреть в каком виде передаются данные по протоколу PPTP использовался анализатор сети Sniffer Pro 2.5 (рисунок 57).

При VPN соединении клиента Windows 98 с сервером Windows2000 было перехвачено 100 пакетов.

Защита информации виртуальных частных сетей

Рисунок 57 – перехваченные пакеты

Окно разделено на три части: основная информация, детальная информация и содержимое пакета в шестнадцатеричном виде.

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

PPTP посылает управляющую информацию через протокол TCP, а данные - через протокол Generic Routing Encapsulation (GRE).

На рисунке 57 видно, что в основном идёт обмен пакетами по протоколу GRE.

Посмотрим содержимое пакетов переданных с помощью протокола GRE.

Защита информации виртуальных частных сетей

Рисунок 58 – перехваченные пакеты

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

Посмотрим еще пакет:

Защита информации виртуальных частных сетей

Рисунок 59 – перехваченные пакеты

Для сравнения посмотрим пакет переданный по протоколу TCP:

Защита информации виртуальных частных сетей

Рисунок 60 – перехваченные пакеты

На рисунке 60 видно, что пакет не содержит зашифрованных данных. До места отмеченного серым цветом идёт информация об IP, а затем о TCP.

Заключение

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

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

Microsoft продолжает развивать свои технологии виртуальных частных сетей, чтобы предложить пользователям хорошо интегрированные и безопасные средства организации ВЧС. Применение протокола PPTP дает организациям возможность легко и с минимальными затратами прокладывать туннели через общедоступные сети, предупреждая при этом несанкционированное их использование. Возможности PPTP прекрасно дополняет протокол MPPE, обеспечивающий дополнительное шифрование данных, передаваемых по туннелю. А протоколы L2TP, IPSec и EAP, поддержка которых предусмотрена в Windows 2000, сделают доступными и другие методы аутентификации, включая применение микропроцессорных карточек.

Прекрасно осознавая динамический характер сетевых угроз, Microsoft пытается предвосхитить будущие требования к безопасности сетей, для чего обращает повышенное внимание на развитие средств защиты сетевых операций. Ее усилия в этой области привели к дальнейшему повышению безопасности ВЧС на базе PPTP за счет:

расширенной аутентификации по протоколу MS-CHAP;

применения для аутентификации более стойких паролей;

применения дополнительных средств шифрования на базе протокола MPPE;

защиты канала управления.

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

Дипломная работа: Защита информации виртуальных частных сетей

Похожие работы: