Курс "Защита информации", кафедра радиотехники, Московский физико-технический институт (МФТИ)

2010: Главная Экзамен Лекции Семинары Проекты Эссе | Преподаватели Литература | Архив: 2009 2008-fall 2008 2007 2006 2005 2004 2003 | English
HTML-версия эссе "Maintaning VPN tunnel for mobile user", Safonov, 2004, сгенерированная из pdf/rtf.
Конвертация не вcегда корректна. Смотрите исходный pdf.

Эссе по курсу защита информации

студента 011 гр. Сафонова А.А.

Удержание VPN tunnel мобильным пользователем

Удержание VPN tunnel мобильным пользователем

Большинство компаний сегодня используют различные формы VPN (Virtual Private Network) для безопасного доступа к корпоративным ресурсам через Интернет. VPN-канал обычно ассоциируется с IP-адресом устройства. Это составляет проблему для мобильного пользователя, потому что IP-адрес его устройства меняется каждый раз, когда пользова-тель меняет подсеть в процессе движения. Реализованные в настоящий момент версии VPN предполагают пользователю пройти процедуры аутентификации и распределения ключей заново и установить новое VPN соединение. Так, например, протокол IKE (Internet Key Exchange) должен быть полностью выполнен заново, и установлен новый IPSec tunnel. В условиях, когда пользовательское устройство не обладает большой вычисли-тельной мощностью (а мобильные устройства чаще всего именно такие) и wireless-соединение достаточно медленно, все процедуры аутентификации отнимают значительное время, что особенно ощутимо для real-time приложений. В настоящем эссе на примере IP-Sec и IKE-protocol излагается простой и эффективный способ (один из авторов Yi Cheng; метод был предложен на шестой международной конференции по беспроводным техноло-гиям в Японии в 2003г) удержать уже установленное безопасное соединение, несмотря на то, что IP-адрес устройства поменялся. Основная идея метода состоит в том, чтобы дина-мически ассоциировать IP-адрес устройства с уже установленной сессией безопасного со-единения. Вместо того чтобы повторять процедуры IKE-protocol, достаточно обменяться парой коротких сообщений, что существенно повышает производительность и экономит время и трафик.

1. Введение

VPN (Virtual Private Network) каналы широко используются мобильными пользовате-лями для безопасного доступа к корпоративным ресурсам через Интернет. VPN-канал устанавливается между пользовательским устройством и безопасным шлюзом, кото-рый соединяет корпоративную сеть с внешним миром. И, казалось бы, VPN-канал не должен обрываться и для мобильного пользователя, ведь оба конца канала: удаленное устройство и шлюз - остались теми же самыми. Но на практике, каждый раз, когда пользователь перемещается из одной подсети в другую, приходится устанавливать VPN-канал заново. Так происходит, потому что канал привязывается к IP-адресу поль-зовательского устройства, который меняется вместе с подсетью. Например, в IPSec безопасная сессия характеризуется тремя параметрами: Security Parameter Index (SPI), IP Destination Address, Security Protocol (AH или ESP). Каждый раз, когда пользова-тельское устройство получает новый адрес, установленная сессия уничтожается.

Поэтому мобильному пользователю придется периодически выполнять соединение за-ново. Но даже если пользователь не движется, IP-адрес его устройства все равно мо-жет поменяться. Так произойдет если, к примеру, пользователь переключится на дру-гую технологию доступа: например, с GPRS на Wireless LAN, чтобы работать с боль-шей скоростью. И тогда все равно придется «переустанавливать» VPN соединение.

Установка VPN соединения подразумевает выполнение процедур аутентификации и распределения ключей. Например, процедуры IKE (Internet Key Exchange) protocol должны быть полностью повторены, чтобы установить новый IPSec канал. Эти проце-дуры занимают много времени. Небольшая пропускная способность беспроводных се-тей и скромная вычислительная мощность мобильного устройства усугубляют ситуа-цию. Так, например, с GPRS соединением процедуры протокола IKE занимают 4-6 се-кунд! Поэтому пользовательские приложения, особенно чувствительные к задержкам в работе сети, могут дать серьезные сбои.

2. Динамическая привязка IP-адреса

Для того чтобы избежать повторной установки VPN-канала, можно предложить дина-мически «привязывать» IP-адрес мобильного устройства к уже установленной безо-пасной сессии (security associations) защищенным способом.

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

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

Чтобы такая схема работала должны быть выполнены следующие условия:

• Должна использоваться аутентификация пользователя, а не устройства.
• Установленный защищенный канал после аутентификации не должен быть же-стко привязан к IP-адресу мобильного устройства. В противном случае, после смены IP-адреса, канал будет более недоступен.
• Специальное сообщение об обновлении привязки должно быть аутентифициро-вано и защищено от re-play атаки.

Т.к. IPSec одно из наиболее распространенных VPN решений, в дальнейшем будет об-суждать именно эта реализация VPN канала. Хотя, тот же подход может быть исполь-зован и для других реализаций.

2.1 IKE и IKE Config

IKEv1

Протокол IKE, как описано в RFC 2409, состоит из двух частей. В первой части две стороны (peers) аутентифицируют друг друга и устанавливают защищенный канал. При этом устанавливается безопасная сессия (security associations), которая называется ISAKMP SA. Во второй части по установленному защищенному каналу стороны «до-говариваются» о деталях IPSec или другого сервиса. Привязка нового IP-адреса может происходить в любое время после этих переговоров по установленному в первой части защищенному каналу.

IKE Config

IKE Config – это межсетевой шаблон (draft), представляющий способ использования канала ISAKMP SA для безопасного обмена конфигурационной информацией в рамках IKEv1. Обычно IKE Config используется для передачи мобильным устройствам внут-рисетевых параметров, таких как свободные IP-адреса, адреса DNS (Domain Name Ser-vice), DHCP (Dynamic Host Configuration Protocol), etc. Эта информация передается в специальных полях шаблона.

IKEv2

Эта версия IKE protocol намного проще и удобнее, чем IKEv1. В ней восемь возмож-ных сценариев, определенных в IKEv1, объединены всего в 4 инициализирующих со-общения. IKEv2 позволяет устанавливать дочерние сессии (security associations) на этапе инициализации. IKEv2 включает поддержку NAT, расширенную аутентифика-цию (extended authentication) и некоторые другие дополнительные возможности.

Т.к. IKEv1 распространен все еще гораздо шире, чем IKEv2, проиллюстрируем воз-можность динамической привязки IP-адреса с помощью IKE Config.

2.2 Configuration Exchange

Допустим, мобильное устройство и корпоративный шлюз установили IPSec канал, ис-пользуя протокол IKE. В некоторый момент IP-адрес устройства меняется. Если мо-бильное устройство хочет удержать установленную сессию, оно инициализирует про-цедуру configuration exchange, посылая специальное сообщение AddrUpdateRec шлюзу (рис. 1). Это сообщение содержит необходимые для configuration exchange заголовки (ISAKMP Header), хеш-функцию (Hash Payload) и набор передаваемых атрибутов (At-tribute Payload). Для наших целей нужно взять в качестве атрибутов идентификатор пользователя (User ID), старый IP-адрес мобильного устройства и новый IP-адрес.

При получении такого сообщения (AddrUpdateRec) корпоративный шлюз «поднимает» уже установленную сессию, основываясь на информации cookies в заголовке ISAKMP Header. Шлюз расшифровывает остальную часть сообщения и аутентифицирует его, проверяя хеш-функцию (Hash Payload). Кроме того, шлюз проверяет, правильные ли идентификатор пользователя и старый IP-адрес его устройства. В случае если настрой-ки Corporate Security Policy допускают динамическую привязку IP-адреса, шлюз отве-чает подтверждающим сообщением AddrUpdateAck. Это сообщение содержит новый IP-адрес в поле передаваемых атрибутов (Attribute Payload). Затем шлюз ассоциирует существующую сессию (IPSec Security Associations) с новым IP-адресом и меняет ад-рес в списке сессий (Security Associations Database). С этого момента мобильное уст-ройство может продолжать «общаться» с корпоративным шлюзом.

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

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

Шлюз должен сверять новый IP-адрес, указанный в сообщении, с адресом отправителя этого сообщения (source address). Эти адреса могут не совпадать в двух случаях. Воз-можно, это злоумышленник перехватил сообщение и изменил у него адрес отправите-ля, пытаясь провести denial-of-service (DOS) атаку. В этом случае нужно игнорировать адрес отправителя и привязывать указанный в сообщении IP-адрес к установленной сессии.

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

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

2.3 Анализ защищенности

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

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

Что реально может сделать злоумышленник, так это изменить адрес отправителя со-общения AddrUpdateReq (source address). Успех подобной атаки зависит от того, ис-пользуется ли технология NAT. Если NAT не используется, и в сообщении указан ре-альный IP-адрес, то именно его шлюз и привяжет к установленной безопасной сессии. Измененный злоумышленником адрес отправителя будет просто проигнорирован шлюзом. Таким образом, атака не даст результатов.

Если же технология NAT используется, то шлюзу придется обращать внимание на ад-рес отправителя сообщения AddrUpdateReq. И в случае, если он был изменен зло-умышленником, шлюз привяжет именно его к безопасной сессии пользователя. Сами пакеты закодированы, и злоумышленнику никакой пользы не принесут. Но мобильный пользователь потеряет сессию, и ему придется заново устанавливать VPN-канал. Та-ким образом, единственным результатом атаки может стать потеря соединения поль-зователем.

2.4 Производительность

Без динамической привязки адресов мобильное устройство вынуждено повторять, по крайней мере, вторую часть протокола IKE. Большинство же приложений выполняет и первую часть этого протокола тоже. Вторая часть включает синхронизацию сессий, генерацию ключей и т.д. Эти процедуры могут отнять гораздо больше времени у мо-бильного устройства с небольшими вычислительными возможностями, чем можно предположить. Как указывалось ранее, с GPRS соединением, например, инструкции протокола IKE занимают 4-6 секунд.

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

3. Заключение

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

4. Литература
1. “WPMC ‘03” The 6th International Symposium on Wireless Personal Multimedia Com-munications. http://www.ilcc.com/WPMC/index.html , 2003г.

paper: Maintaining Security Associations for Seamless Mobile VPN

paper’s author: Yi Cheng, “Wireless Corporate Access Ericsson Enterprise AB”, 2003г, SE-126 25 Stockholm, Sweden


Page last update: Fri Jun 10 10:12:29 2005 MSD.
Website last update:
Rambler's Top100 Рейтинг@Mail.ru