Информация. ИНФОРМАЦИОННАЯ БЕЗОПАСНОСТЬ. В. Ф. Шаньгининформационная безопасность компьютерных систем
 Скачать 5.69 Mb.
|
|
Глава 11 ЗАЩИТА НА КАНАЛЬНОМ И СЕАНСОВОМ УРОВНЯХ Виртуальный защищенный канал можно построить с помо щью системных средств, реализованных на разных уровнях мо дели взаимодействия открытых систем OSI. От выбранного ра бочего уровня OSI зависит функциональность реализуемой VPN и ее совместимость с приложениями КИС, а также с другими средствами защиты. Средства VPN, применяемые на канальном уровне модели OSI, позволяют обеспечить инкапсуляцию различных видов тра фика третьего уровня (и выше) и построение виртуальных тун нелей типа «точка—точка» (от маршрутизатора к маршрутизато ру или от персонального компьютера к шлюзу ЛВС). При построении защищенных виртуальных сетей на сеансо вом уровне появляется возможность криптографической защиты информационного обмена, включая аутентификацию, а также реализации ряда функций посредничества между взаимодейст вующими сторонами. 11.1. Протоколы формирования защищенных каналов на канальном уровне Протоколы РРТР (Point-to-Point Tunneling Protocol), L2F (Layer-2 Forwarding) и L2TP (Layer-2 Tunneling Protocol) — это протоколы туннелирования канального уровня модели OS1. Об щим свойством этих протоколов является то, что они использу ются для организации защищенного многопротокольного уда ленного доступа к ресурсам корпоративной сети через открытую сеть, например через Интернет. Все три протокола — РРТР, L2F и L2TP — обычно относят к протоколам формирования защищенного канала, однако этому определению точно соответствует только протокол РРТР, кото рый обеспечивает туннелирование и шифрование передаваемых данных. Протоколы L2F и L2TP поддерживают только функции туннелирования. Для защиты туннелируемых данных в этих про токолах необходимо использовать некоторый дополнительный протокол, в частности IPSec. Клиентское ПО обычно использует для удаленного доступа стандартный протокол канального уровня РРР (Point-to-Point Protocol). Протоколы РРТР, L2F и L2TP основываются на прото коле РРР и являются его расширениями. Первоначально прото кол РРР, расположенный на канальном уровне, был разработан для инкапсуляции данных и их доставки по соединениям типа «точка—точка». Этот протокол служит также для организации асинхронных (например, коммутируемых) соединений. В частно сти, в настройках коммутируемого доступа удаленных систем Windows 2000 или Windows 9х обычно указывается подключение к серверу по протоколу РРР. В набор РРР входят протокол управления соединением LCP (Link Control Protocol), ответственный за конфигурацию, уста новку, работу и завершение соединения «точка—точка», и прото кол управления сетью NCP (Network Control Protocol), способ ный инкапсулировать в РРР протоколы сетевого уровня для транспортировки через соединение «точка—точка». Это позволя ет одновременно передавать пакеты Novell IPX и Microsoft IP по одному соединению РРР. Для доставки конфиденциальных данных из одной точки в другую через сети общего пользования сначала производится инкапсуляция данных с помощью протокола РРР, затем прото колы РРТР и L2TP выполняют шифрование данных и собствен ную инкапсуляцию. После того как туннельный протокол дос тавляет пакеты из начальной точки туннеля в конечную, выпол няется деинкапсуляция. На физическом и канальном уровнях протоколы РРТР и L2TP идентичны, но на этом их сходство заканчивается и начи наются различия. 11.1.1. П р о т о ко л РРТР Протокол РРТР (Point-to-Point Tunneling Protocol), разрабо танный компанией Microsoft при поддержке других компаний, предназначен для создания защищенных виртуальных каналов при доступе удаленных пользователей к локальным сетям через Интернет. Он предполагает создание криптозащищенного тун неля на канальном уровне модели OSI как для случая прямого соединения удаленного компьютера с открытой сетью, так и для случая подсоединения его к открытой сети по телефонной ли нии через провайдера [9, 32]. Протокол РРТР получил практическое распространение бла годаря компании Microsoft, реализовавшей его в своих ОС Win dows NT/2000. Некоторые производители МЭ и шлюзов VPN также поддерживают этот протокол. Протокол РРТР позволяет создавать защищенные каналы для обмена данными по протоко лам IP, IPX или NetBEUI. Данные этих протоколов упаковыва ются в кадры РРР и затем инкапсулируются посредством прото кола РРТР в пакеты протокола IP, с помощью которого перено сятся в зашифрованном виде через любую сеть TCP/IP. Пакеты, передаваемые в рамках сессии РРТР, имеют следую щую структуру (рис. 11.1): • заголовок канального уровня, используемый внутри Ин тернета, например заголовок кадра Ethernet; • заголовок IP, содержащий адреса отправителя и получателя пакета; • заголовок общего метода инкапсуляции для маршрутиза ции GRE (Generic Routing Encapsulation); • исходный пакет РРР, включающий пакет IP, IPX или NetBEUI. Заголовок IP- GRE- РРР- Зашифрованные Окончание кадра заголовок заголовок эаголовок данные кадра передачи РРР передачи Рис. 11.1. Структура пакета для пересылки по туннелю РРТР Принимающий узел сети извлекает из пакетов IP кадры РРР, а затем извлекает из кадра РРР исходный пакет IP, IPX или NetBEUI и отправляет его по локальной сети конкретному адре сату. Многопротокольность инкапсулирующих протоколов ка- іб* нального уровня, к которым относится протокол РРТР, является их важным преимуществом перед протоколами защищенного ка нала более высоких уровней. Например, если в корпоративной сети используются IPX или NetBEUI, применение протоколов IPSec или SSL просто невозможно, поскольку они ориентирова ны только на один протокол сетевого уровня IP. Такой способ инкапсуляции обеспечивает независимость от протоколов сетевого уровня модели OSI и позволяет осуществ лять защищенный удаленный доступ через открытые IP-сети к любым локальным сетям (IP, IPX или NetBEUI). Согласно про токолу РРТР при создании защищенного виртуального канала производится аутентификация удаленного пользователя и шиф рование передаваемых данных (рис. 11.2). Рис. 11.2. Архитектура протокола РРТР Для аутентификации удаленного пользователя могут исполь зоваться различные протоколы, применяемые для РРР. В реали зации РРТР, включенной компанией Microsoft в Windows 98/ NT/2000, поддерживаются следующие протоколы аутентифика ции: протокол распознавания по паролю PAP (Password Authen tication Protocol), протокол распознавания при рукопожатии MSCHAP (Microsoft Challenge-Handshaking Authentication Proto col) и протокол распознавания EAP-TLS (Extensible Authen tication Protocol — Transport Layer Security). При использовании протокола PAP идентификаторы и пароли передаются по линии связи в незашифрованном виде, при этом только сервер прово дит аутентификацию клиента. При использовании протоколов MSCHAP и EAP-TLS обеспечиваются защита от повторного ис пользования злоумышленником перехваченных пакетов с за шифрованным паролем и взаимная аутентификация клиента и VPN-сервера. Шифрование с помощью РРТР гарантирует, что никто не сможет получить доступ к данным при пересылке через Internet. Протокол шифрования МРРЕ (Microsoft Point-to-Point Encryp tion) совместим только с MSCHAP (версии 1 и 2) и EAP-TLS и умеет автоматически выбирать длину ключа шифрования при согласовании параметров между клиентом и сервером. Протокол МРРЕ поддерживает работу с ключами длиной 40, 56 или 128 бит. Протокол РРТР изменяет значение ключа шифрования по сле каждого принятого пакета. Для протокола РРТР определены две основные схемы при менения: 1) схема туннелирования при прямом соединении удаленно го компьютера с Интернетом; 2) схема туннелирования при подключении удаленного ком пьютера к Интернету по телефонной линии через провайдера [32, 45]. Рассмотрим реализацию 1-й схемы туннелирования (рис. 11.3). Удаленный пользователь устанавливает удаленное соединение с локальной сетью с помощью клиентской части сервиса удален ного доступа RAS (Remote Access Service), входящего в состав Windows 98/NT. Затем пользователь обращается к серверу уда ленного доступа локальной сети, указывая его IP-адрес, и уста навливает с ним связь по протоколу РРТР. Локальная сеть Рис. 11.3. Схема туннелирования при прямом подсоединении компьютера удаленного пользователя к Internet Функции сервера удаленного доступа может выполнять по граничный маршрутизатор локальной сети. На компьютере уда ленного пользователя должны быть установлены клиентская часть сервиса RAS и драйвер РРТР, которые входят в состав Windows 98/NT, а на сервере удаленного доступа локальной сети — сервер RAS и драйвер РРТР, входящие в состав Win dows NT Server. Протокол РРТР определяет несколько служеб ных сообщений, которыми обмениваются взаимодействующие стороны. Служебные сообщения передаются по протоколу TCP. После успешной аутентификации начинается процесс защищен ного информационного обмена. Внутренние серверы локальной сети могут не поддерживать протокол РРТР, поскольку погра ничный маршрутизатор извлекает кадры РРР из пакетов IP и посылает их по локальной сети в необходимом формате — IP, IPX или NetBIOS. 2-я схема туннелирования не получила широкого распро странения. 1 1 .1 .2 . Протокол L2TP Протокол L2F (Layer-2 Forwarding) был разработан компани ей Cisco Systems для построения защищенных виртуальных сетей на канальном уровне модели OSI как альтернатива протоколу РРТР. Однако в настоящее время он фактически поглощен прото колом L2TP, поэтому далее будут рассматриваться основные возможности и свойства протокола L2TP. Протокол L2TP (Layer-2 Tunneling Protocol) разработан в ор ганизации IETF (Internet Engineering Task Force) при поддержке компаний Microsoft и Cisco Systems. Протокол L2TP разрабаты вался как протокол защищенного туннелирования РРР-трафика через сети общего назначения с произвольной средой. Работа над этим протоколом велась на основе протоколов РРТР и L2F, и в результате он вобрал в себя лучшие качества исходных про токолов [9]. В отличие от РРТР, протокол L2TP не привязан к протоколу IP, поэтому он может быть использован в сетях с коммутацией пакетов, например в сетях ATM (Asynchronous Transfer Mode) или в сетях с ретрансляцией кадров (frame relay). Кроме того, в протокол L2TP добавлена важная функция управления потока ми данных, а также ряд отсутствующих в спецификации прото кола РРТР функций защиты, в частности, включена возмож ность работы с протоколами АН и ESP стека протоколов IPSec (рис. 11.4). Рис. 11.4. Архитектура протокола L2TP В сущности, гибридный протокол L2TP представляет собой расширение протокола РРР функциями аутентификации удален ных пользователей, создания защищенного виртуального соеди нения и управления потоками данных. Протокол L2TP применяет в качестве транспорта протокол UDP и использует одинаковый формат сообщений как для управления туннелем, так и для пересылки данных. Хотя протокол РРТР обеспечивает достаточную степень без опасности, но все же протокол L2TP (поверх IPSec) надежнее. Протокол L2TP (поверх IPSec) обеспечивает аутентификацию на уровнях «пользователь» и «компьютер», а также выполняет ау тентификацию и шифрование данных. После того как L2TP (поверх IPSec) завершает процесс ау тентификации компьютера, выполняется аутентификация на уровне пользователя. В отличие от своих предшественников — протоколов РРТР и L2F, протокол L2TP предоставляет возможность открывать меж ду конечными абонентами сразу несколько туннелей, каждый из которых может быть выделен для отдельного приложения. Эти особенности обеспечивают гибкость и безопасность туннелиро вания. Согласно спецификации протокола L2TP роль сервера уда ленного доступа провайдера должен выполнять концентратор доступа LAC (L2TP Access Concentrator), который обеспечивает удаленному пользователю сетевой доступ к его локальной сети через Интернет. В качестве сервера удаленного доступа локаль ной сети должен выступать сетевой сервер LNS (L2TP Network Server), функционирующий на совместимых с протоколом РРР платформах (рис. 11.5). Локальная сеть Локальная сеть Формирование защищенного виртуального канала в прото коле L2TP осуществляется в три этапа: • установление соединения с сервером удаленного доступа локальной сети; • аутентификация пользователя; • конфигурирование защищенного туннеля [9]. Следует отметить, что протокол L2TP не определяет конкрет ных методов криптозащиты и предполагает возможность приме нения различных стандартов шифрования. Если защищенный туннель планируется сформировать в IP-сетях, тогда для реализа ция криптозащиты используется протокол IPSec. Протокол L2TP поверх IPSec обеспечивает более высокую степень защиты дан ных, чем РРТР, так как использует алгоритм шифрования 3DES или AES. Если такой высокий уровень защиты не нужен, можно использовать алгоритм DES с одним 56-разрядным ключом. Кро ме того, при помощи алгоритма НМАС (Hash Message Authen tication Code) протокол L2TP обеспечивает аутентификацию дан ных, для чего этот алгоритм создает хэш длиной 128 разрядов. Таким образом, функциональные возможности протоколов РРТР и L2TP различны. Протокол РРТР может применяться только в IP-сетях. Протокол L2TP может использоваться не толь ко в IP-сетях. Протокол L2TP поверх IPSec предлагает больше уровней безопасности, чем РРТР, и может гарантировать почти 100%-ю безопасность важных для организации данных. Однако при всех своих достоинствах протокол L2TP не смог преодолеть ряд недостатков туннельной передачи данных на ка нальном уровне: • для реализации протокола L2TP необходима поддержка провайдеров ISP; • протокол L2TP ограничивает трафик рамками выбранного туннеля и лишает пользователей доступа к другим частям Интернета; • спецификация L2TP обеспечивает стандартное шифрова ние только в IP-сетях с помощью протокола IPSec. 11.2. Протоколы формирования защищенных каналов на сеансовом уровне Самым высоким уровнем модели OSI, на котором возможно формирование защищенных виртуальных каналов, является пя тый — сеансовый уровень. При построении защищенных вирту альных сетей на сеансовом уровне появляется возможность криптографической защиты информационного обмена, включая аутентификацию, а также реализации ряда функций посредниче ства между взаимодействующими сторонами. Действительно, сеансовый уровень модели OSI отвечает за установку логических соединений и управление этими соедине ниями. Поэтому существует возможность применения на этом уровне программ-посредников, проверяющих допустимость за прошенных соединений и обеспечивающих выполнение других функций защиты межсетевого взаимодействия. Однако на сеансовом уровне начинается непосредственная зависимость от приложений, реализующих высокоуровневые протоколы. Поэтому реализация протоколов защиты информа ционного обмена, соответствующих этому уровню, в большинст ве случаев требует внесения изменений в высокоуровневые сете вые приложения. Для защиты информационного обмена на сеансовом уровне широкое распространение получил протокол SSL (Secure Sockets Layer). Для выполнения на сеансовом уровне функций посред ничества между взаимодействующими сторонами организацией IETF (Internet Engineering Task Force) в качестве стандарта при нят протокол SOCKS [9]. 1 1 .2 .1 . Протоколы SSL/TLS Протокол SSL применяется в качестве протокола защищен ного канала, работающего на сеансовом уровне модели OSI. Этот протокол использует криптографические методы защиты инфор мации для обеспечения безопасности информационного обмена. Протокол SSL выполняет все функции по созданию защищенно го канала между двумя абонентами сети, включая их взаимную аутентификацию, обеспечение конфиденциальности, целостно сти и аутентичности передаваемых данных. Ядром протокола SSL является технология комплексного использования асимметрич ных и симметричных криптосистем. Взаимная аутентификация обеих сторон в SSL выполняется путем обмена цифровыми сертификатами открытых ключей пользователей (клиента и сервера), заверенными цифровой под писью специальных сертификационных центров. Протокол SSL поддерживает сертификаты, соответствующие общепринятому стандарту Х.509, а также стандарты инфраструктуры открытых ключей РКІ (Public Key Infrastructure), с помощью которой орга низуется выдача и проверка подлинности сертификатов. Конфиденциальность обеспечивается шифрованием переда ваемых сообщений с использованием симметричных сессионных ключей, которыми стороны обмениваются при установлении со единения. Сессионные ключи передаются также в зашифрован ном виде, при этом они шифруются с помощью открытых клю чей, извлеченных из сертификатов абонентов. Использование для защиты сообщений симметричных ключей связано с тем, что скорость процессов шифрования и расшифрования на осно ве симметричного ключа существенно выше, чем при использо вании несимметричных ключей. Подлинность и целостность циркулирующей информации обеспечивается за счет формиро вания и проверки электронной цифровой подписи. В качестве алгоритмов асимметричного шифрования исполь зуются алгоритм RSA, а также алгоритм Диффи — Хеллмана. Допустимыми алгоритмами симметричного шифрования явля ются RC2, RC4, DES, 3DES и AES. Для вычисления хэш-функ ций могут применяться стандарты MD5 и SHA-1. В протоколе SSL версии 3.0 набор криптографических алгоритмов является расширяемым. Согласно протоколу SSL криптозащишенные туннели созда ются между конечными точками виртуальной сети. Инициатора ми каждого защищенного туннеля являются клиент и сервер, функционирующие на компьютерах в конечных точках туннеля (рис. 11.6). пользователя Рис. 11.6. Криптозащищенные туннели, сформированные на основе протокола SSL Протокол SSL предусматривает следующие этапы взаимо действия клиента и сервера при формировании и поддержке за щищаемого соединения: • установление SSL-сессии; • защищенное взаимодействие. В процессе установления SSL-сессии решаются следующие задачи: • аутентификация сторон; • согласование криптографических алгоритмов и алгоритмов сжатия, которые будут использоваться при защищенном информационном обмене; • формирование общего секретного мастер-ключа; • генерация на основе сформированного мастер-ключа общих секретных сеансовых ключей для криптозащиты информа ционного обмена [9, 65]. Процедура установления SSL-сессии, называемая также про цедурой рукопожатия, отрабатывается перед непосредственной защитой информационного обмена и выполняется по протоколу начального приветствия (Handshake Protocol), входящему в со став протокола SSL. При установлении повторных соединений между клиентом и сервером стороны могут, по взаимному соглашению, формиро вать новые сеансовые ключи на основе «старого» общего «секре та» (данная процедура называется «продолжением» SSL сессии). Протокол SSL 3.0 поддерживает три режима аутентификации: • взаимную аутентификацию сторон; • одностороннюю аутентификацию сервера без аутентифика ции клиента; • полную анонимность. При использовании последнего варианта обеспечивается за щита информационного обмена без каких-либо гарантий отно сительно подлинности сторон. В этом случае взаимодействую щие стороны не защищены от атак, связанных с подменой уча стников взаимодействия. В реализациях протокола SSL для аутентификации взаимо действующих сторон и формирования общих секретных ключей обычно используют алгоритм RSA. Соответствие между открытыми ключами и их владельцами устанавливается с помощью цифровых сертификатов, выдавае мых специальными центрами сертификации (см. гл. 13). Протокол SSL прошел проверку временем, работая в попу лярных браузерах Netscape Navigator и Internet Explorer, а также Web-серверах ведущих производителей. В январе 1999 г. на сме ну версии SSL 3.0 пришел протокол TLS (Transport Layer Secu rity), который базируется на протоколе SSL и в настоящее время является стандартом Интернета. Различия между протоколами SSL 3.0 и TLS 1.0 не слишком существенны. Протокол SSL стал промышленным протоколом, развиваемым и продвигаемым вне технических координирующих институтов Internet. Протокол SSL поддерживается ПО серверов и клиентов, вы пускаемых ведущими западными компаниями. Существенным недостатком протокола SSL является то, что практически все продукты, поддерживающие SSL, из-за экспортных ограничений доступны за пределами США лишь в усеченном варианте (с дли ной сеансового ключа 40 бит для алгоритмов симметричного шифрования и 512 бит для алгоритма RSA, используемого на этапе установления SSL-сессии). К недостаткам протоколов SSL и TLS можно отнести то, что для транспортировки своих сообщений они используют только один протокол сетевого уровня — IP, и, следовательно, могут работать только в ІР-сетях. Кроме того, в SSL для аутентификации и шифрования ис пользуются одинаковые ключи, что при определенных условиях может привести к потенциальной уязвимости. Подобное реше ние дает возможность собрать больше статистического материа ла, чем при аутентификации и шифровании разными ключами. 1 1 .2 .2 . Протокол SOCKS Протокол SOCKS организует процедуру взаимодействия клиент-серверных приложений на сеансовом уровне модели OSI через сервер-посредник, или ргоху-сервер [9]. В общем случае программы-посредники, которые традицион но используются в МЭ, могут выполнять следующие функции: • идентификацию и аутентификацию пользователей; • криптозащиту передаваемых данных; • разграничение доступа к ресурсам внутренней сети; • разграничение доступа к ресурсам внешней сети; • фильтрацию и преобразование потока сообщений, напри мер поиск вирусов и прозрачное шифрование информации; • трансляцию внутренних сетевых адресов для исходящих потоков сообщений. Первоначально протокол SOCKS разрабатывался только для перенаправления запросов к серверам со стороны клиентских приложений, а также возврата этим приложениям полученных ответов. Перенаправление запросов и ответов между клиент-сер верными приложениями уже позволяет реализовать функцию трансляции сетевых IP-адресов NAT (Network Address Transla tion). Замена у исходящих пакетов внутренних IP-адресов отпра вителей одним IP-адресом шлюза позволяет скрыть топологию внутренней сети от внешних пользователей и тем самым услож нить задачу НСД. На основе протокола SOCKS могут быть реализованы и дру гие функции посредничества по защите сетевого взаимодействия. Например, протокол SOCKS может применяться для контроля над направлениями информационных потоков и разграничения доступа в зависимости от атрибутов пользователей и информа ции. Эффективность использования протокола SOCKS для вы полнения функций посредничества обеспечивается его ориента цией на сеансовый уровень модели OSI. По сравнению с посред никами прикладного уровня на сеансовом уровне достигается более высокое быстродействие и независимость от высокоуров невых протоколов (HTTP, FTP, POP3, SMTP и др.). Кроме того, протокол SOCKS не привязан к протоколу IP и не зависит от ОС. Например, для обмена информацией между клиентскими прило жениями и посредником может использоваться протокол IPX. Благодаря протоколу SOCKS МЭ и виртуальные частные сети могут организовать безопасное взаимодействие и обмен ин формацией между разными сетями. Протокол SOCKS позволяет реализовать безопасное управление этими системами на основе унифицированной стратегии. Следует отметить, что на основе протокола SOCKS могут создаваться защищенные туннели для каждого приложения и сеанса в отдельности. Согласно спецификации протокола SOCKS различают SOCKS-cepeep, который целесообразно устанавливать на шлюз (МЭ) сети, и SOCKS-клиент, который устанавливают на каждый пользовательский компьютер. SOCKS-сервер обеспечивает взаи модействие с любым прикладным сервером от имени соответст вующего этому серверу прикладного клиента. SOCKS-клиент предназначен для перехвата всех запросов к прикладному серве ру со стороны клиента и передачи их SOCKS-серверу. Следует отметить, что SOCKS-клиенты, выполняющие перехват запросов клиентских приложений и взаимодействие с SOCKS-сервером, могут быть встроены в универсальные клиентские программы. SOCKS-серверу известно о трафике на уровне сеанса (сокета), поэтому он может осуществлять тщательный контроль и, в част ности, блокировать работу конкретных приложений пользовате лей, если они не имеют необходимых полномочий на информа ционный обмен. Протокол SOCKS ѵ5 одобрен организацией IETF (Internet Engineering Task Force) в качестве стандарта Internet и включен в RFC 1928 [9]. Общая схема установления соединения по протоколу SOCKS ѵ5 может быть описана следующим образом: • запрос прикладного клиента, желающего установить сое динение с каким-либо прикладным сервером в сети, пере хватывает установленный на этом же компьютере SOCKS- клиент; • соединившись с SOCKS-сервером, SOCKS-клиент сообща ет ему идентификаторы всех методов аутентификации, ко торые он поддерживает; • SOCKS-сервер решает, каким методом аутентификации воспользоваться (если SOCKS-сервер не поддерживает ни один из методов аутентификации, предложенных SOCKS- клиентом, соединение разрывается); • при поддержке каких-либо предложенных методов аутен тификации SOCKS-сервер в соответствии с выбранным методом аутентифицирует пользователя, от имени которого выступает SOCKS-клиент; в случае безуспешной аутенти фикации SOCKS-сервер разрывает соединение; • после успешной аутентификации SOCKS-клиент передает SOCKS-серверу DNS-имя или IP-адрес запрашиваемого прикладного сервера в сети и далее SOCKS-сервер на ос нове имеющихся правил разграничения доступа принимает решение об установлении соединения с этим прикладным сервером; • в случае установления соединения прикладной клиент и прикладной сервер взаимодействуют друг с другом по це почке соединений, в которой SOCKS-сервер ретранслирует данные, а также может выполнять функции посредничест ва по защите сетевого взаимодействия; например, если в ходе аутентификации SOCKS-клиент и SOCKS-сервер об менялись сеансовым ключом, то весь трафик между ними может шифроваться. Аутентификация пользователя, выполняемая SOCKS-серве- ром, может основываться на цифровых сертификатах в формате Х.509 или паролях. Для шифрования трафика между SOCKS- клиентом и SOCKS-сервером могут быть использованы протоко лы, ориентированные на сеансовый или более низкие уровни модели OSI. Кроме аутентификации пользователей, трансляции IP-адресов и криптозащиты трафика, SOCKS-сервер может вы полнять также такие функции, как: • разграничение доступа к ресурсам внутренней сети; • разграничение доступа к ресурсам внешней сети; • фильтрация потока сообщений, например, динамический поиск вирусов; • регистрация событий и реагирование на задаваемые собы тия; • кэширование данных, запрашиваемых из внешней сети. Протокол SOCKS осуществляет встроенную поддержку по пулярных Web-навигаторов Netscape Navigator и Netscape Com municator компании Netscape, а также Internet Explorer компании Microsoft. Специальные программы, называемые соксификаторами, до полняют клиентские приложения поддержкой протокола SOCKS. К таким программам относится, например, NEC SocksCap и др. При установке соксификатор внедряется между пользовательски ми приложениями и стеком коммуникационных протоколов. Да лее в процессе работы он перехватывает коммуникационные вы зовы, формируемые приложениями, и перенаправляет их в случае надобности на SOCKS-сервер. При отсутствии нарушений уста новленных правил безопасности работа SOCKS-клиента совер шенно прозрачна для клиентских приложений и пользователей. Таким образом, для формирования защищенных виртуаль ных сетей по протоколу SOCKS в точке сопряжения каждой локальной сети с Интернетом на компьютере-шлюзе устанавли вается SOCKS-сервер, а на рабочих станциях в локальных сетях и на компьютерах удаленных пользователей устанавливаются SOCKS-клиенты. По существу, SOCKS-сервер можно рассмат ривать как МЭ, поддерживающий протокол SOCKS (рис. 11.7). Удаленные пользователи могут подключаться к Интернету лю бым способом — по коммутируемой или выделенной линии. При попытке пользователя защищенной виртуальной сети установить Рис. 11.7. Схема взаимодействия по протоколу SOCKS соединение с каким-либо прикладным сервером SOCKS-клиент начинает взаимодействовать с SOCKS-сервером. По завершении первого этапа взаимодействия пользователь будет аутентифици рован, а проверка правил доступа покажет, имеет ли он право соединиться с конкретным серверным приложением, функцио нирующем на компьютере с указанным адресом. Дальнейшее взаимодействие может происходить по криптографически защи щенному каналу [45]. Помимо защиты локальной сети от НСД, на SOCKS-сервер может возлагаться контроль доступа пользователей этой локаль ной сети к открытым ресурсам Интернета (Telnet, WWW, SMTP, POP и др.). Доступ является полностью авторизованным, так как идентифицируются и аутентифицируются конкретные пользова тели, а не компьютеры, с которых они входят в сеть. Правила доступа могут запрещать или разрешать соединения с конкрет ными ресурсами Интернета в зависимости от полномочий кон кретного сотрудника. Действие правил доступа может зависеть и от других параметров, например от метода аутентификации или времени суток. В дополнение к функциям разграничения доступа может вы полняться регистрация событий и реагирование на задаваемые события. Для достижения более высокой степени безопасности сетевого взаимодействия серверы локальной сети, к которым разрешен доступ со стороны Интернета, должны быть выделены в отдельный подсоединяемый к SOCKS-серверу сегмент, обра зующий защищаемую открытую подсеть. 11.3. Защита беспроводных сетей Беспроводные сети начинают использоваться практически во всем мире. Это обусловлено их удобством, гибкостью и сравни тельно невысокой стоимостью. Беспроводные технологии долж ны удовлетворять ряду требований к качеству, скорости, радиусу приема и защищенности, причем защищенность часто является самым важным фактором. Сложность обеспечения безопасности беспроводной сети очевидна. Если в проводных сетях злоумышленник должен сна чала получить физический доступ к кабельной системе или око нечным устройствам, то в беспроводных сетях это условие отпа дает само собой: поскольку данные передаются «по воздуху», для получения доступа достаточно обычного приемника, установ ленного в радиусе действия сети (см. разд. 2.2.3). Однако, несмотря на различия в реализации, подход к безо пасности беспроводных сетей и их проводных аналогов иденти чен: здесь присутствуют аналогичные требования к обеспечению конфиденциальности и целостности передаваемых данных и, ко нечно же, к проверке подлинности как беспроводных клиентов, так и точек доступа. Общие сведения Как и все стандарты IEEE 802, базовый стандарт организа ции беспроводных локальных сетей IEEE 802.11 работает на нижних двух уровнях модели ISO/OSI — физическом и каналь ном. Сетевое приложение, сетевая ОС или протокол (например, TCP/IP) будут так же хорошо работать в сети 802.11, как и в сети Ethernet. Основная архитектура, особенности и службы определяются в базовом стандарте 802.11 (см. разд. 4.2), который определяет два режима работы беспроводной сети — режим клиент/сервер (или режим инфраструктуры) и режим «точка—точка» (Ad-hoc). В режиме клиент/сервер беспроводная сеть состоит как мини мум из одной точки доступа АР (Access point), подключенной к проводной сети, и некоторого набора беспроводных оконечных станций. Такая конфигурация носит название базового набора служб BSS (Basic Service Set). Два или более BSS, образующих единую подсеть, формируют расширенный набор служб ESS (Exten ded Service Set). Так как большинству беспроводных станций тре буется получать доступ к файловым серверам, принтерам, Интер нету, доступным в проводной локальной сети, они будут работать в режиме клиент/сервер. Режим «точка—точка» — это простая сеть, в которой связь между многочисленными станциями устанавливается напрямую, без использования специальной точки доступа. Такой режим по лезен в том случае, если инфраструктура беспроводной сети не сформирована (например, в отеле, выставочном зале, аэропорту). На физическом уровне стандарта 802.11 определены 2 широ кополосных радиочастотных метода передачи и 1 — в инфра красном диапазоне. Радиочастотные методы работают в ISM диа пазоне 2,4 ГГц и обычно используют полосу 83 МГц от 2,400 ГГц до 2,483 ГГц. Технологии широкополосного сигнала, используе мые в радиочастотных методах, увеличивают надежность, пропу скную способность, позволяют многим несвязанным друг с дру гом устройствам разделять одну полосу частот с минимальными помехами друг для друга. Основное дополнение, внесенное стандартом 802.11b в ос новной стандарт, — это поддержка двух новых скоростей пере дачи данных — 5,5 и 11 Mbps. Для достижения этих скоростей был выбран метод прямой последовательности DSSS (Direct Sequence Spread Spectrum). Канальный (Data Link) уровень стандарта 802.11 состоит из двух подуровней: управления логической связью LLC (Logical Link Control) и управления доступом к носителю MAC (Media Access Control). Обеспечение безопасности беспроводных сетей Система защиты беспроводных сетей WLAN, основанная на протоколе WEP (Wired Equivalent Privacy) первоначального стан дарта 802.11, имеет существенные недостатки. Однако появились более эффективные технологии обеспечения информационной безопасности WLAN, которые описаны в стандарте WPA (Wi-Fi Protected Access) организации Wi-Fi Alliance и стандарте 802.11 і института IEEE и призваны устранить недостатки стандарта 802.11. Поскольку процесс разработки стандарта 802.11 і слиш ком затянулся, организация Wi-Fi Alliance была вынуждена предложить в 2002 г. собственную технологию обеспечения ин формационной безопасности WLAN — стандарт WPA. Стандарт WPA весьма привлекателен тем, что относительно прост в реализации и позволяет защитить ныне действующие WLAN. Стандарты WPA и 802.11і совместимы друг с другом, по этому использование поддерживающих WPA продуктов можно считать начальным этапом перехода к системе защиты на базе стандарта 802.11і (см. разд. 4.2). Между технологиями стандартов 802.11 і и WPA много обще го. Так, в них определена идентичная архитектура системы безо пасности с улучшенными механизмами аутентификации пользо вателей и протоколами распространения и обновления ключей. Но есть и существенные различия. Например, технология WPA базируется на протоколе динамических ключей TKIP (Temporal Key Integrity Protocol), поддержку которого в большинстве уст ройств WLAN можно реализовать путем обновления их ПО, а в более функциональной концепции стандарта 802.11і пред усмотрено использование нового стандарта шифрования AES (Advanced Encryption Standard), с которым совместимо лишь но вейшее оборудование для WLAN. В стандарте WPA предусмотрено использование защитных протоколов 802.1х, ЕАР, ТКІР и RADIUS. Механизм аутентификации пользователей основан на прото коле контроля доступа 802.1х (разработан для проводных сетей) и протоколе расширенной аутентификации ЕАР (Extensible Authentication Protocol). Последний позволяет сетевому админи стратору задействовать алгоритмы аутентификации пользовате лей посредством сервера RADIUS (см. гл. 13). Функции обеспечения конфиденциальности и целостности данных базируются на протоколе ТКІР, который в отличие от протокола WEP использует более эффективный механизм управ ления ключами, но тот же самый алгоритм RC4 для шифрования данных. Согласно протоколу ТКІР, сетевые устройства работают с 48-битовым вектором инициализации (в отличие от 24-битово го вектора инициализации протокола WEP) и реализуют правила изменения последовательности его битов, что исключает повтор ное использование ключей и осуществление геріау-атак. В протоколе ТКІР предусмотрены генерация нового ключа для каждого передаваемого пакета и улучшенный контроль це лостности сообщений с помощью криптографической контроль ной суммы MIC (Message Integrity Code), препятствующей хаке ру изменять содержимое передаваемых пакетов. Система сетевой безопасности стандарта WPA работает в двух режимах: PSK (Pre-Shared Key) и Enterprise (корпоратив ный). Для развертывания системы, работающей в режиме PSK, необходим разделяемый пароль. Такую систему несложно уста навливать, но она защищает WLAN не столь надежно, как это делает система, функционирующая в режиме Enterprise с иерар хией динамических ключей. Хотя протокол ТКІР работает с тем же самым блочным шифром RC4, который предусмотрен специ фикацией протокола WEP, технология WPA защищает данные надежнее последнего. Чтобы точки доступа WLAN стали совместимыми со стан дартом WPA, достаточно модернизировать их ПО. Для перевода же сетевой инфраструктуры на стандарт 802.11і потребуется но вое оборудование, поддерживающее алгоритм шифрования AES, так как AES-шифрование создает большую нагрузку на цен тральный процессор беспроводного клиентского устройства. Чтобы корпоративные точки доступа работали в системе сетевой безопасности стандарта WPA или 802.11і, они должны поддерживать аутентификацию пользователей по протоколу RADIUS и реализовывать предусмотренный стандартом метод шифрования — ТКІР или AES, что потребует модернизации их ПО. И еще одно требование — быстро осуществлять повтор ную аутентификацию пользователей после разрыва соединения с сетью. Это особенно важно для нормального функционирования приложений, работающих в реальном масштабе времени. Если сервер RADIUS, применяемый для контроля доступа пользователей проводной сети, поддерживает нужные методы аутентификации ЕАР, то его можно задействовать и для аутенти фикации пользователей WLAN. В противном случае следует ус тановить сервер WLAN RADIUS. Этот сервер работает следую щим образом: сначала он проверяет аутентифицирующую ин формацию пользователя (на соответствие содержимому своей БД об их идентификаторах и паролях) или его цифровой серти фикат, а затем активизирует динамическую генерацию ключей шифрования точкой доступа и клиентской системой для каждо го сеанса связи. Для работы технологии WPA требуется механизм EAP-TLS (Transport Layer Security), тогда как в стандарте ІЕЕЕ 802.1 И применение конкретных методов аутентификации ЕАР не огова ривается. Выбор метода аутентификации ЕАР определяется спе цификой работы клиентских приложений и архитектурой сети. Чтобы ноутбуки и карманные ПК работали в системе сетевой безопасности стандарта WPA или 802.11і, они должны быть ос нащены клиентскими программами, поддерживающими стан дарт 802.1х. Самым простым, с точки зрения развертывания, вариантом системы сетевой безопасности стандарта WPA является система, работающая в режиме PSK. Она предназначена для небольших и домашних офисов и не нуждается в сервере RADIUS, а для шифрования пакетов и расчета криптографической контрольной суммы MIC в ней используется пароль PSK. Обеспечиваемый ею уровень информационной безопасности сети вполне достаточен для большинства вышеуказанных офисов. С целью повышения эффективности защиты данных следует применять пароли, со держащие не менее 20 символов. Предприятиям целесообразно внедрять у себя системы сете вой безопасности стандарта WPA с серверами RADIUS. Боль шинство компаний предпочитают именно такие системы, по скольку работающие в режиме PSK решения сложнее админист рировать и они более уязвимы для хакерских атак. До тех пор пока средства стандарта 802.11 і не станут доступ ными на рынке, WPA будет оставаться самым подходящим стан дартом для защиты WLAN. Стандарты WPA и 802.11і в достаточной степени надежны и обеспечивают высокий уровень защищенности беспроводных се тей. Тем не менее одного протокола защиты недостаточно — следует также уделять внимание правильному построению и на стройке сети. Физическая защита. При развертывании Wi-Fi-сети необхо димо физически ограничить доступ к беспроводным точкам. Правильная настройка. Парадокс современных беспроводных сетей заключается в том, что пользователи не всегда включают и используют встроенные механизмы аутентификации и шиф рования. Защита пользовательских устройств. Не следует полностью полагаться на встроенные механизмы защиты сети. Наиболее оптимальным является метод эшелонированной обороны, пер вая линия которой — средства защиты, установленные на ста ционарном ПК, ноутбуке или КПК. Традиционные меры. Эффективная работа компьютера в сети немыслима без классических мер защиты — своевременной уста новки обновлений, использования защитных механизмов, встро енных в ОС и приложения, а также антивирусов. Однако этих мер на сегодня недостаточно, так как они ориентированы на за щиту от уже известных угроз. Мониторинг сети. Слабое звено в корпоративной сети — са мовольно установленные точки доступа. Актуальной является за дача локализации несанкционированных точек доступа. Специ альные средства локализации точек доступа позволяют графиче ски отображать место расположения «чужого» терминала на карте этажа или здания. Если классические методы не спасают от вторжения, следует применять системы обнаружения атак. VPN-агенты. Многие точки доступа работают в открытом ре жиме, поэтому необходимо использовать методы защиты переда ваемых данных. На защищаемом компьютере должен быть уста новлен VPN-клиент, который возьмет на себя решение этой за дачи. Практически все современные ОС (например, Windows ХР) содержат в своем составе такие программные компоненты. |