IPsec это набор открытых стандартов для безопасной передачи данных через публичные сети. Как правило, для этого используются виртуальные частные сети VPN.
VPN может обеспечивать несколько видов защиты данных, включая конфиденциальность, целостность, аутентификацию источника данных, контроль доступа, защиту от replay атак. Несмотря на то, что VPN уменьшают риск компрометации данных, они не устраняют его полностью, так как реализация VPN может иметь ошибки алгоритмов, ПО или VPN может быть организована с небезопасными настройками.
Существует три основных модели VPN:
-Шлюз-шлюз. Защищает передачу данных между двумя конкретными сетями, например основным офисом организации и филиалом.
-Шлюз-хост. Защищает передачу данных между одним или более отдельным хостом и конкретной сетью, принадлежащей организации. Чаще всего применяется для того, чтобы позволить хостам, подключающимся через небезопасные сети (например удаленным работникам, или работникам находящимся в командировке) получать доступ к внутренним ресурсам организации.
-Хост-хост. Защищает передачу данных между двумя конкретными хостами. Чаще всего использвется в случаях, когда небольшое количество пользователей подключается к системе с использованием небезопасных протоколов.
Рекомендуемые к использованию алегоритмы шифрования: AES, 3DES
Рекомендуемые стадии организации VPN:
-Определить потребности
-Разработать решение
-Протестировать прототип
-Развернуть решение
-Управлять решением
IPSec представляет собой набор протоколов. Основными его комонентами являются:
-Encapsulating securiy payload (ESP)
-Authentication heade (AH)
-Internet key exchange (IKE)
AH обеспечивает проверку целостности заголовков пакетов и данных, и аутентификацию источника данных. AH не имеет функции шифрования. AH был необходим, когда ESP не имел функций аутентификации. После того, как такие функции были добавлены в ESP во второй версии IPSec, AH стал менее значимым. Фактически, отдельные программные реализации IPSec не используют AH вовсе. Тем не менее, AH по-прежнему важен, т.к. обеспечивает аутентификацию отдельных частей пакетов, а именно внешнего (outermost) заголовка пакета, чего не может ESP.
AH имеет 2 режима: транспортный (transport) и туннельный (tunnel). В туннельном режиме для каждого пакета создается новый заголовок, в транспортном - нет. Независимо от режима, AH обеспечивает защиту целостности пакета (целостность данных, которые могут непредсказуемо меняться при передаче пакета, например TTL, не обеспечивается).
Защита целостности и аутентификация иточника данных производятся с помощью создания хэша (hash) с использованием алгоритма message authentication code (MAC). Данный алгоритм используюет ключ (т.н. keyed hash algorithm), т.е. для создания хэша используется не только само сообщение, но и секретный ключ, которым обладают стороны, устанавливающие соединение.
Примерами таких алгоритмов являются HMAC-MD5, HMAC-SHA1, AES Cipher Block Chaining MAC.
Таким образом, AH, используюя разделяемый ключ или сертификат, вычисляет значение хэш-функции для блока данных в каждом пакете. С помощью этого значения другая сторона соединения может убедиться, что данные отправлены надежным источником (не злоумышленником) и что они не были изменены в процессе передачи.
AH зачастую несовместим с NAT, т.к. при замене IP-адреса источика в пакете он не проходит проверку целостности. Тем не менее, существуют технологии, позволяющие обойти это ограничение (см. далее).
ESP обеспечивает шифрование данных в пакете, а также защиту целостности и аутетификацию. ESP не обеспечивает защиту целостности внешнего (outermost) заголовка пакета. Шифрование в ESP может быть отключено, таким образом, данный протокол может обеспечивать только шифрование, только защиту целостности/аутентификацию, или шифрование и защиту целостности/аутентификацию одновременно.
ESP может работат в двух режимах: транспортном (transport) и туннельном (tunnel). В туннельном режиме ESP создает новый IP заголовок для каждого пакета. Новый заголовок содержит адреса конечных точек ESP-туннеля (например шлюзов IPSEC). Т.о. ESP может полностью зашифровать исходный пакет, скрывая, тем самым, данные и исходные адреса источника и назначения, а также обеспечить проверку целостности оригинального пакета и своего заголовка (ESP-header), что позволяет удостовериться, что данные не были изменены в процессе передачи. Также шифруется ESP-трейлер.
В транспортном режиме ESP использует заголовок IP исходного пакета, таким образом скрываются только данные в исходном пакете и некоторые компоненты ESP, но не исходные адреса источника и назначения. Данный режим используется в основном в модели хост-хост.
ESP шифрует пакеты симметрично. Когда конечная точка (endpoint) шифрует данные, она делит их на маленькие блоки (128 бит в случае с AES), и производит набор криптографических операций используя данные блоки и ключ. Другая конечная точка, получая данные, расшифровывает данные, используя тот же ключ.
ESP добавляет к каждому пакету заголовок и трейлер.
Заголовок состоит из двух полей:
-SPI Каждая конечная точка соединения IPSEC имеет произвольное значение SPI, которое служит уникальным идентификатором соединения. Принимающая сторона использует значение SPI вместе с адресом назначения и (опционально) типом протокола IPSec, чтобы определить какая SA используется.
-Номер (sequence number) каждому пакету назначается последовательный номер, и только пакеты в рамках скользящего окна номеров принимаются конечными точками. Это позвояет защититься от атак воспроизведением (replay attacks), т.к. дублирующиеся пакеты будут использовать тот же номер. Так же этот метод помогает против DoS атак, т.к. "старые" пакеты, т.е. пакеты не попадающие в "окно" будут сразу же отбрасываться без затраты ресурсов на их обработку.
Трейлер состоит из двух обязательных и одного опционального поля:
-Набивка (padding). Пакет ESP может опционально содержать набивку, т.е. дополнительные байты, которые увеличивают пакет и после отбрасываются принимающей стороной. Т.к. ESP использует шифрование блоками, набивка может быть необходима, чтобы размер шифрованных данных делился нацело на размер блока. Также набивка может использоваться, чтобы изменить размер каждого пакеты, скрыв таким образом реальный размер зашифрованных данных.
-Длина набивки (padding length) - показывает сколько байт составляет длина набивки. Обязательное поле.
-Следующий заголовок (next header). В туннельном режиме инкапсулируется, как правило, IP пакет, следовательно значение будет 4 для IP-in-IP. В транспортном режиме инкапсулируется, как правило протокол 4 уровня, т.е. TCP (6) или UDP (17). Обязательное поле.
Если включена проверка целостности ESP, то за трейлером следует поле информации об аутентификации (authentication information field). Как и AH, данное поле содержит результат обработки содержимого пакета хэш-функцией. В отличие от AH не обрабатывает внешний (outermost) IP заголовок.
ESP снача шифрует, а потом аутентифицирует данные.
Назначение протокола IKE (Internet key exchange) - согласование, создание и управление ассоциациями безопасности (security associations, SA). SA - общий термин, обозначающий набор значений, которые определяют функционал и защиту, примененные к соединению. SA могут создаваться вручную с использованием значений, заранее обговоренных сторонами, но они не могут обновляться, что делает такой способ неприемлемым для для крупных реализаций VPN. IKE использует 5 разных типов обмена, чтобы создать SA. В IPSec IKE используется чтобы обеспечить безопасный механизм создания соединений.
Фаза 1 (phase 1 exchange)
Цель данной фазы - создание участниками IPSEC соединения безопасного канала, через который будет проводено согласование SA. Этот канал, как правило, называется IKE SA. Его цель - обеспечить двунаправленное шифрование и аутентификацию для последующего обмена данными IKE. Пока данная фаза не завершится успешно, другие не могут начаться и соединение не может быть установлено. Создание канала на этой фазе может проиходить в двух режимах: основном (main) и агрессивном (aggressive).
В основном режиме стороны обмениваются тремя парами сообщений. В первой паре каждая сторона предлагает параметры, которые будут использоваться для SA. Сторона, инициирующая соединение, может предлагать несколько значений для каждого параметра. Т.к. разных комбинаций очень много, рекомендуется использовать одни и те же параметры для обеих сторон.
Четыре параметра (т.н. protection suite) являются обязательными:
-алгоритм шифрования (encryption algorithm) - алгоритм, который будет использоваться для шифрования даных, например DES, 3DES, CAST, RC5, IDEA, Blowfish, AES
-алгоритм проверки целостности (integrity protection algorithm) - key-hashed алгоримт который будет использоваться для проверки целостности, например HMAC-MD5 HMAC-SHA-1
-метод аутентификации:
секретный ключ (pre-shared key)
электронные подписи (digital signatures) используется алгоритм RSA или DSS. Данные подписываются с помощью сертификатов.
шифрование методом публичного ключа (public key encrypriotn) - сертификаты используются не для подписи, а для шифрования данных. Как правило треует PKI.
-группы Диффи-Хеллмана (Diffie-Hellman (DH) Group) - алгоритм Диффи-Хеллмана используется для того, чтобы сгенерированить пароль для сторон таким образом, чтобы сторонний наблюдатель не мог его узнать. Данный пароль требуется для фаз 1 и 2.
Во второй паре сообщений происходит обмен ключами, в третьей стороны соединения аутентифицируют друг друга.
В агрессивном режиме происходит согласование тех же параметров, что в основном, однако используется всего 3 сообщения вместо 3 пар сообщений. Таким образом, соединение устанавливается быстрее, но процесс становится менее безопасным, поэтому рекомендуется использовать основной режим.
Фаза 2 (phase 2 exchange)
На 2 фазе происходит установление SA непосредственно для IPSec соединения (IPSec SA). В отличие от IKE SA, которые являются двусторонними, IPSec SA односторонние, соответственно соединение требует двух SA. Установление IPSec SA возможно в единственном, быстром режиме (quick mode), который использует 3 сообщения: 1. сторона А отправляет ключи, предложения параметров IPSEC SA, nonce (одноразовый пароль для предотвращения replay-атак). При этом в процессе может быть включена опция Perfec Forward Security (PFS), в результате чего с помощью алгоритма Диффи-Хеллмана формируются новые пароли для каждой SA. Хотя PFS генерирует больше трафика при установлении SA, данная опция повышает безопасность соединения. 2. сторона B отпрвляет ключи, выбранные параметры SA, nonce, а также хэш для аутентификации 3. сторона A отправляет хэш для аутентификации.
Все активные SA хранятся в SAD (Security association database). Для каждого защищенного соединения SA содержат следующую информацию:
-адрес источника
-адрес назначения
-SPI
-протокол безопасности IPSec (AH или ESP)
-Режим (транспортный или туннельный)
-Алгоритм шифрования
-Алгоритм проверки целостности
-Секретные ключи, используемые выбранными алгоритмами
-Длина ключа (если какие-либо из выбранных алгоритмов используют ключи различной длины)
-Время жизни SA
-Информация о номере (sequence number)
-Информация для защиты от replay-атак
-Типы трафика, к которым применяются SA (например конкретные порты и/или протоколы).
Каждая SA может быть уникально идентифицирована по сочетанию 3 параметров: адрес назначени, spi, протокол безопасности IPSec.
Когда стороне требуется узнать какая SA применяется к конкретному пакету, она обращается к SAD используюя указанные 3 параметра.
Одна SA может исопользоваться для AH или для ESP. Т.о. если используется AH и ESP одновременно, для установления двустороннего соедениения требуется 4 SA.
Однако, SAD не описывает какие типы трафика следует защищать и при каких обстоятельствах. Такая информация хранится в SPD (security policy database), которая классифицирует трафик, как требующий защиты (protect), не требующий защиты (bypass), или запрещенный (discard). Как правило, SPD содержит следущую информациюдля трафика, требующего защиты:
-адрес источника и назначения
-IP протокол (TCP, UDP и т.д.)
-номер порта (опционально)
-защита IPSec, которая применяется к трафику
-указатель на SA в SAD
Доступ к SPD должен иметь только администратор. После того, как истекает время жизни SA, создаются новые. Данный процесс называется rekeying. Время жизни (lifetime) SA может определяться временным промежутком (не более 24 часов) или объемом траффика.
В протоколе IKE версии 2 реализован ряд изменений:
-определен одним RFC
-протокол упрощен (убран ряд избыточных функций, таких как агрессивный режим, обмен групп (group exchange), аутентификация через публичные ключи)
-надежная передача сообщений
-дополнительная защита от DoS атак
-поддержка EAP (возможна аутентификация по Kerberos и Radius)
Данные в пакетах могут сжиматься перед шифрованием средствами протокола IP payload compression protocol (IPComp). Данные могут сжиматься как в одном, так и в двух направлениях.
Протокол ISAKMP используется для создания SA и управления ими. Обеспечивает только фреймворк для обмена ключами. Сам процесс обмена происходит независимо от ISAKMP.
Основные факторы, которые следует иметь ввиду при размещениий vpn-шлюза:
-производительность устройства (операции шифрования интенсивно используют процессор)
-проверка трафика (файрволлы и СОВ не могут проверять шифрованный трафик. следует размещать их таким образом, чтобы проверялся трафик после рашсифровки)
-трафик не защищенный IPSec (например если впн-шлюз располагается вне файрволла, следует убедиться, что расшифрованный трафик, проходящий между впн-шлюзом и файрволом не подвергается риску)
-отказоустойчивость
-NAT. Так как в процессе трансляции адресов меняется адрес источника в заголовке пакета, в результате чего пакет не проходит проврку целостности IPSec. Существуют следующие решения: 1. Транслировать адреса до применения IPSec 2. Инкапсулировать ESP-пакеты в UDP-датаграммы (т.е. использовать ESP в туннельном режиме, или транспортный режим ESP с протоколом L2TP).
Функция IKE, известная как IPSec NAT Traversal (NAT-T) позволяет IKE согласовывать использование UDP-инкапсуляции. Обе стороны сообщают о поддержке NAT-T, после чего производится обнаружение NAT (каждая сторона отправляет хэш своего сетевого адреса), другая сторона сравнивает этот хеш с хешем адреса в полученном пакете, определяяя таким образом использовался ли NAT при передаче пакета. После этого, IKE начинает использовать порт 4500 вместо 500, чтобы избежать конфликтов.
При выборе впн-клиента следует принимать во внимании вопрос разделенных (split) туннелей, когда клиент находится в публичной сети и трафик, идущий в сеть организации проходит через туннель, остальной трафик - через публичную сеть. Это может быть опасно, т.к. атакующий, подключившись к компьютеру клиента может попасть в локальную сеть организации. Отдельные программные продукты для установления впн-соединений могут предотвращать появление разделенных туннелей, а также отключать все сетевые интерфейсы, кроме того, через который устанавливается впн-соединение.
Аутентификация.
Аутентифиация в IPSec может происходить с помощью разделяемого ключа и электронных подписей.
Хотя разделяемый ключ проще в настройке, с ним возникает ряд сложностей: 1. Если одиному из хостов, имевших доступ ранее, следует его запретить, разделяемый ключ следует поменять у всех остальных хостов 2. Ключи следует периодически обновлять для уменьшения негативных последствий его возможной компреметации 3. Лицо получившее доступ к ключу в одной из точек подключения, может получить доступ также в одной или несокльких других точках.
Т.о. по соображениям масштабируемости и безопасности, разделяемый ключ следует использовать только для небольших групп устройств с известными адресами или небольшим набором адресов. Также разделяемый ключ не рекомендуется использовать, если хосты не имеют статического адреса (например удаленные работники).
Разделяемые ключи можно использовать на стадии внедрения и тестирования IPSec с последующей сменой метода аутентификации.
При использовании электронных сертификатов каждое устройство имеет идентифицирующий его сертификат (также могут использоваться сертификаты для пользователей). Два узла IPSec будут доверять друг другу, есть их сертификаты подписаны Certification Authority (CA), которым оба доверяют. Для управления сертификатами разворачивается публичная инфраструктура ключей (Public Key Infrastructure, PKI).
Хотя данный метод и является более надежным и масштабируемым, у него есть свои недостатки. При установлении соединения, должна проводиться проверка сертификата. За время проведение проверки сертификата сессия IKE может оборваться по тайм-ауту.
Т.к. при использовании цифровых подписей размер пакетов увеличивается, могут возникнуть проблемы с фрагментацией.
Фильтры пакетов (packet fileters)
Их целью является разделение трафика на нуждающийся и не нуждающийся в защите. По умолчанию защищается весь трафик, однако в некоторых случаях это нежелательно т.к. отрицательно влияет на производительность. Например, шифрование уже зашифрованного трафика является, по сути, тратой ресурсов. Для уже зашифрованного трафика имеет смысл отключать шифрование IPSec, оставляя только проверку целостности или просто пересылать без какой-либо защиты.
Некоторые типы трафика, например широковещательный и мультикаст трафик, несоввметсимы с IPSec.
Важные факторы при внедрении IPSec:
-Следует реализовать и поддерживать меры безопасности, дополняющие vpn: брандмауэры и антивирусы на конечных точках подключения, контроль "здоровья" конечных точек, ограничение доступа к vpn-шлюзам и т.д.
-время жизни SA. Для тестов можно выставлять кортокие (5-10 минут), в рабочих реализациях обычное время жизни IKE SA - 24 часа (86400 секунд), IPSec SA - 8 часов (28800 секунд). Важно, чтобы у пиров были одинаковые настройки времени жизни SA, т.к. некоторые реализации IPSec разрываюет IKE сессию, если пир предлагает время жизни более долгое, чем имеющееся в настройках.
-Фаза 1 IKE: везде, где возможно следует использовать main mode, т.к. предлагает более стойкую защиту.
-Группы диффи-хеллмана. Следует использовать настройки групп, соответсвующие совеременным стандартам. На 2014 год Cisco рекомендует группы 15 и 16 (3072-bit 4096-bit DH), либо 19 и 20 (256-bit and 384-bit ECDH). Следует учитывать производительноть оборудования при выборе групп Диффи-Хеллмана, т.к например группы 15, 16 могут не поддерживаться на аппаратном уровне, а обработка их на уровне ПО может перегружать процессор.
-Алгоритмы шифрования и аутентификации. Рекомендуется использовать как алгоритм шифрования так и алгоритм аутентификации. Рекомендация Cisco на 2014 год: AES 128 (AES-256 для секретной информации), SHA-1 (SHA 256 или SHA 384 для секретной информации).
-Для повышения уровня безопасности следует включать PFS. На этапе внедрения данную технологию можно не задействовать, но рекомендуется протестировать и запустить ее после того, как настроен базовый функционал IPSec.
-Реагирование на инциденты. Следует подготовить эффективный сценарий действия на случай компрометации IPSec ифраструктуры. Например, если скомпрометирован компьютер пользователя следует отозвать сертификат или удалить разделяемый ключ.
-Управление журналами. Следует собирать и хранить логи IPSec для того, чтобы устранять проблемы и расследовать инциденты.
-Резервирование.
-Совместимость оборудования и программного обеспечения. Не все реализации IPSec совметсимы друг с другом.
-Хранение разделяемых ключей. Ключи не должны храниться в текстовом виде. Доступ к файлам с ключами должны иметь только администраторы. На системе где хранятся ключи должне работать брандмауэр (желательно ИДС).
-Периодически в реализация IPSec находятся уязвимости. Следует отслеживать такую информацию и принмать меры к устранению "дыр".
-Шифрованый трафик может негативно сказаться на производительности сетевого оборудования (в т.ч. бранмауэров, ИДС, QoS)
-Управление решением. Следует документировать решение и изменения в нем, поддерживать актуальность программного обеспечения, обновлять настройки в соответсвии с современными требованиями к безопасности, следить за корректной работой и производительностью сетевого оборудования.
VPN-протоколы канального уровня
Т.к. эти протоколы работают на канальном уровне, с ними совместимы различные сетевые протоколы, такие как IP, IPX, NetBEUI. Большинство VPN-протоколов, включая IPSec, поддерживают только IP.
Наиболее распространенные VPN-протоколы канального уровня работают поверх PPP. PPP (Point-to-Point Protocol) предназначен для создания соединения между ДВУМЯ узлами и может инкапсулировать пакеты разных протоколов сетевого уровня и мультиплексировать их, используя одну линию.
PPP может обеспечивать шифрование и аутентификацию, но так как для этого используются алгоритмы, не обеспечивающие достаточного уровня защиты информации, используются другие протоколы канального уровня, предоставляющие более надежное шифрование и аутентификацию: PPTT, L2TP, L2F.
PPP в таких реализациях ТОЛЬКО ИНКАПСУЛИРУЕТ.
PPTP
Протокол, разработанный Майкрософт. Обеспечивает защищенный канал между клиентом и сервером. Использует IP протокол 47 (GRE) для передачи данных. ПОЗВОЛЯЕТ ТУННЕЛИРОВАТЬ PPP ЧЕРЕЗ IP СЕТИ. Используются собственный механизм шифрования (Microsoft Point-to-Point encryption, MPPE) и авторизации (PAP, CHAP, CHAPv2). На данный момент эти механизмы имеют известные уязвимости, соответственно использование для передачи конфиденциальных данных не рекомендуется.
L2F
Проприетарный протокол Cisco. Предназначен для шифрования трафика между сетевыми устройствами, например сервером доступа сервис-провайдера и ВПН-шлюзом организации. Пользователь подключается к серверу провайдера, сервер распознает пользовательский трафик, как требующий защиты, производите аутентификацию впн-шлюза организации и пользователя и обеспечивает защиту трафика между сервером и впн-шлюзом. При этом трафик между пользователем и серверов провайдера остается незащищенным.
L2TP
Протокол, разработанный IETF, призван объединить и модернизировать PPTP и L2F. Защищенные соединения устанавливаются между клиентом и сервером. Вместо GRE использует собственный туннельный протокол (UDP порт 1701). Поддерживает несколько сессий в одном туннеле. Помимо аутентификации PPP может использовать RADIUS и TACACS+. Может использовать IPSec для шифрования и управления ключами. Может работать не только через IP-сети (но и ATM, X.25, Frame Relay). Для аутентифиации данных используется HMAC MD5. Для взаимной аутентификации клиента и сервера используется разделяемый ключ или сертификаты. После того, как завершена аутентификация клиента и сервера происходит аутентификация пользователя и использованием одного из протоклов PPP (PAP, CHAP. при этом к моменту начала аутентификации пользователя соединение уже зашифровано, следовательно аутентификацию пользователя можно проводить даже с помощью PAP).
Преимущества L2TP+IPSec:
-Более надежная защита данных
-Более надежная аутентификация (как для уровне компьютера, так и на уровне пользователя)
-Может работать через сети отличные от IP
Преимущества PPTP:
-Не требует PKI или механизма управления разделяемыми ключами
-Можно использовать на компьютерах со стаыми ОС
-Может использоваться даже если клиент и сервер находятся за NAT-устройством (при условии, что сделаны соответствующие настройки NAT). Клиент и сервер L2TP могут располагаться за NAT-устройством только при условии что оба поддерживают NAT-T.
Обратить внимание: если не требуется туннелирование протоколов канального уровня, можно использоваться IPSec в туннельном режиме чтобы генерировать меньше overhead траффика (PPP и GRE заголовки).
Источники:
NIST Special Publication 800-77b Guide to IPsec VPNs Recommendations of the National Institute of Standards and Technology
Sheila Frankel, Karen Kent, Ryan Lewkowski, Angela D. Orebaugh, Ronald W. Ritchey, Steven R. Sharma
Рекомендации Cisco по выбору алгоритмов:
http://www.cisco.com/web/about/security/intelligence/nextgen_crypto.html
Презентация APNIC об IPSec:
http://www.youtube.com/watch?v=gnUIgSvx3OE
http://windowsitpro.com/networking/pptp-vs-l2tp
https://msdn.microsoft.com/en-us/library/bb742566.aspx
RFC:
4301 - the internet security architecture
4302 - AH
4303 - ESP
2048 - ISAKMP
5996 - IKEv2
4835 - cryptographic algorithm implementation for ESP and AH
1661 - The Point-to-Point Protocol (PPP)
2637 - Point-to-Point Tunneling Protocol, available at
2784 - Generic Routing Encapsulation (GRE)
VPN может обеспечивать несколько видов защиты данных, включая конфиденциальность, целостность, аутентификацию источника данных, контроль доступа, защиту от replay атак. Несмотря на то, что VPN уменьшают риск компрометации данных, они не устраняют его полностью, так как реализация VPN может иметь ошибки алгоритмов, ПО или VPN может быть организована с небезопасными настройками.
Существует три основных модели VPN:
-Шлюз-шлюз. Защищает передачу данных между двумя конкретными сетями, например основным офисом организации и филиалом.
-Шлюз-хост. Защищает передачу данных между одним или более отдельным хостом и конкретной сетью, принадлежащей организации. Чаще всего применяется для того, чтобы позволить хостам, подключающимся через небезопасные сети (например удаленным работникам, или работникам находящимся в командировке) получать доступ к внутренним ресурсам организации.
-Хост-хост. Защищает передачу данных между двумя конкретными хостами. Чаще всего использвется в случаях, когда небольшое количество пользователей подключается к системе с использованием небезопасных протоколов.
Рекомендуемые к использованию алегоритмы шифрования: AES, 3DES
Рекомендуемые стадии организации VPN:
-Определить потребности
-Разработать решение
-Протестировать прототип
-Развернуть решение
-Управлять решением
IPSec представляет собой набор протоколов. Основными его комонентами являются:
-Encapsulating securiy payload (ESP)
-Authentication heade (AH)
-Internet key exchange (IKE)
AH обеспечивает проверку целостности заголовков пакетов и данных, и аутентификацию источника данных. AH не имеет функции шифрования. AH был необходим, когда ESP не имел функций аутентификации. После того, как такие функции были добавлены в ESP во второй версии IPSec, AH стал менее значимым. Фактически, отдельные программные реализации IPSec не используют AH вовсе. Тем не менее, AH по-прежнему важен, т.к. обеспечивает аутентификацию отдельных частей пакетов, а именно внешнего (outermost) заголовка пакета, чего не может ESP.
AH имеет 2 режима: транспортный (transport) и туннельный (tunnel). В туннельном режиме для каждого пакета создается новый заголовок, в транспортном - нет. Независимо от режима, AH обеспечивает защиту целостности пакета (целостность данных, которые могут непредсказуемо меняться при передаче пакета, например TTL, не обеспечивается).
Защита целостности и аутентификация иточника данных производятся с помощью создания хэша (hash) с использованием алгоритма message authentication code (MAC). Данный алгоритм используюет ключ (т.н. keyed hash algorithm), т.е. для создания хэша используется не только само сообщение, но и секретный ключ, которым обладают стороны, устанавливающие соединение.
Примерами таких алгоритмов являются HMAC-MD5, HMAC-SHA1, AES Cipher Block Chaining MAC.
Таким образом, AH, используюя разделяемый ключ или сертификат, вычисляет значение хэш-функции для блока данных в каждом пакете. С помощью этого значения другая сторона соединения может убедиться, что данные отправлены надежным источником (не злоумышленником) и что они не были изменены в процессе передачи.
AH зачастую несовместим с NAT, т.к. при замене IP-адреса источика в пакете он не проходит проверку целостности. Тем не менее, существуют технологии, позволяющие обойти это ограничение (см. далее).
ESP обеспечивает шифрование данных в пакете, а также защиту целостности и аутетификацию. ESP не обеспечивает защиту целостности внешнего (outermost) заголовка пакета. Шифрование в ESP может быть отключено, таким образом, данный протокол может обеспечивать только шифрование, только защиту целостности/аутентификацию, или шифрование и защиту целостности/аутентификацию одновременно.
ESP может работат в двух режимах: транспортном (transport) и туннельном (tunnel). В туннельном режиме ESP создает новый IP заголовок для каждого пакета. Новый заголовок содержит адреса конечных точек ESP-туннеля (например шлюзов IPSEC). Т.о. ESP может полностью зашифровать исходный пакет, скрывая, тем самым, данные и исходные адреса источника и назначения, а также обеспечить проверку целостности оригинального пакета и своего заголовка (ESP-header), что позволяет удостовериться, что данные не были изменены в процессе передачи. Также шифруется ESP-трейлер.
В транспортном режиме ESP использует заголовок IP исходного пакета, таким образом скрываются только данные в исходном пакете и некоторые компоненты ESP, но не исходные адреса источника и назначения. Данный режим используется в основном в модели хост-хост.
ESP шифрует пакеты симметрично. Когда конечная точка (endpoint) шифрует данные, она делит их на маленькие блоки (128 бит в случае с AES), и производит набор криптографических операций используя данные блоки и ключ. Другая конечная точка, получая данные, расшифровывает данные, используя тот же ключ.
ESP добавляет к каждому пакету заголовок и трейлер.
Заголовок состоит из двух полей:
-SPI Каждая конечная точка соединения IPSEC имеет произвольное значение SPI, которое служит уникальным идентификатором соединения. Принимающая сторона использует значение SPI вместе с адресом назначения и (опционально) типом протокола IPSec, чтобы определить какая SA используется.
-Номер (sequence number) каждому пакету назначается последовательный номер, и только пакеты в рамках скользящего окна номеров принимаются конечными точками. Это позвояет защититься от атак воспроизведением (replay attacks), т.к. дублирующиеся пакеты будут использовать тот же номер. Так же этот метод помогает против DoS атак, т.к. "старые" пакеты, т.е. пакеты не попадающие в "окно" будут сразу же отбрасываться без затраты ресурсов на их обработку.
Трейлер состоит из двух обязательных и одного опционального поля:
-Набивка (padding). Пакет ESP может опционально содержать набивку, т.е. дополнительные байты, которые увеличивают пакет и после отбрасываются принимающей стороной. Т.к. ESP использует шифрование блоками, набивка может быть необходима, чтобы размер шифрованных данных делился нацело на размер блока. Также набивка может использоваться, чтобы изменить размер каждого пакеты, скрыв таким образом реальный размер зашифрованных данных.
-Длина набивки (padding length) - показывает сколько байт составляет длина набивки. Обязательное поле.
-Следующий заголовок (next header). В туннельном режиме инкапсулируется, как правило, IP пакет, следовательно значение будет 4 для IP-in-IP. В транспортном режиме инкапсулируется, как правило протокол 4 уровня, т.е. TCP (6) или UDP (17). Обязательное поле.
Если включена проверка целостности ESP, то за трейлером следует поле информации об аутентификации (authentication information field). Как и AH, данное поле содержит результат обработки содержимого пакета хэш-функцией. В отличие от AH не обрабатывает внешний (outermost) IP заголовок.
ESP снача шифрует, а потом аутентифицирует данные.
Назначение протокола IKE (Internet key exchange) - согласование, создание и управление ассоциациями безопасности (security associations, SA). SA - общий термин, обозначающий набор значений, которые определяют функционал и защиту, примененные к соединению. SA могут создаваться вручную с использованием значений, заранее обговоренных сторонами, но они не могут обновляться, что делает такой способ неприемлемым для для крупных реализаций VPN. IKE использует 5 разных типов обмена, чтобы создать SA. В IPSec IKE используется чтобы обеспечить безопасный механизм создания соединений.
Фаза 1 (phase 1 exchange)
Цель данной фазы - создание участниками IPSEC соединения безопасного канала, через который будет проводено согласование SA. Этот канал, как правило, называется IKE SA. Его цель - обеспечить двунаправленное шифрование и аутентификацию для последующего обмена данными IKE. Пока данная фаза не завершится успешно, другие не могут начаться и соединение не может быть установлено. Создание канала на этой фазе может проиходить в двух режимах: основном (main) и агрессивном (aggressive).
В основном режиме стороны обмениваются тремя парами сообщений. В первой паре каждая сторона предлагает параметры, которые будут использоваться для SA. Сторона, инициирующая соединение, может предлагать несколько значений для каждого параметра. Т.к. разных комбинаций очень много, рекомендуется использовать одни и те же параметры для обеих сторон.
Четыре параметра (т.н. protection suite) являются обязательными:
-алгоритм шифрования (encryption algorithm) - алгоритм, который будет использоваться для шифрования даных, например DES, 3DES, CAST, RC5, IDEA, Blowfish, AES
-алгоритм проверки целостности (integrity protection algorithm) - key-hashed алгоримт который будет использоваться для проверки целостности, например HMAC-MD5 HMAC-SHA-1
-метод аутентификации:
секретный ключ (pre-shared key)
электронные подписи (digital signatures) используется алгоритм RSA или DSS. Данные подписываются с помощью сертификатов.
шифрование методом публичного ключа (public key encrypriotn) - сертификаты используются не для подписи, а для шифрования данных. Как правило треует PKI.
-группы Диффи-Хеллмана (Diffie-Hellman (DH) Group) - алгоритм Диффи-Хеллмана используется для того, чтобы сгенерированить пароль для сторон таким образом, чтобы сторонний наблюдатель не мог его узнать. Данный пароль требуется для фаз 1 и 2.
Во второй паре сообщений происходит обмен ключами, в третьей стороны соединения аутентифицируют друг друга.
В агрессивном режиме происходит согласование тех же параметров, что в основном, однако используется всего 3 сообщения вместо 3 пар сообщений. Таким образом, соединение устанавливается быстрее, но процесс становится менее безопасным, поэтому рекомендуется использовать основной режим.
Фаза 2 (phase 2 exchange)
На 2 фазе происходит установление SA непосредственно для IPSec соединения (IPSec SA). В отличие от IKE SA, которые являются двусторонними, IPSec SA односторонние, соответственно соединение требует двух SA. Установление IPSec SA возможно в единственном, быстром режиме (quick mode), который использует 3 сообщения: 1. сторона А отправляет ключи, предложения параметров IPSEC SA, nonce (одноразовый пароль для предотвращения replay-атак). При этом в процессе может быть включена опция Perfec Forward Security (PFS), в результате чего с помощью алгоритма Диффи-Хеллмана формируются новые пароли для каждой SA. Хотя PFS генерирует больше трафика при установлении SA, данная опция повышает безопасность соединения. 2. сторона B отпрвляет ключи, выбранные параметры SA, nonce, а также хэш для аутентификации 3. сторона A отправляет хэш для аутентификации.
Все активные SA хранятся в SAD (Security association database). Для каждого защищенного соединения SA содержат следующую информацию:
-адрес источника
-адрес назначения
-SPI
-протокол безопасности IPSec (AH или ESP)
-Режим (транспортный или туннельный)
-Алгоритм шифрования
-Алгоритм проверки целостности
-Секретные ключи, используемые выбранными алгоритмами
-Длина ключа (если какие-либо из выбранных алгоритмов используют ключи различной длины)
-Время жизни SA
-Информация о номере (sequence number)
-Информация для защиты от replay-атак
-Типы трафика, к которым применяются SA (например конкретные порты и/или протоколы).
Каждая SA может быть уникально идентифицирована по сочетанию 3 параметров: адрес назначени, spi, протокол безопасности IPSec.
Когда стороне требуется узнать какая SA применяется к конкретному пакету, она обращается к SAD используюя указанные 3 параметра.
Одна SA может исопользоваться для AH или для ESP. Т.о. если используется AH и ESP одновременно, для установления двустороннего соедениения требуется 4 SA.
Однако, SAD не описывает какие типы трафика следует защищать и при каких обстоятельствах. Такая информация хранится в SPD (security policy database), которая классифицирует трафик, как требующий защиты (protect), не требующий защиты (bypass), или запрещенный (discard). Как правило, SPD содержит следущую информациюдля трафика, требующего защиты:
-адрес источника и назначения
-IP протокол (TCP, UDP и т.д.)
-номер порта (опционально)
-защита IPSec, которая применяется к трафику
-указатель на SA в SAD
Доступ к SPD должен иметь только администратор. После того, как истекает время жизни SA, создаются новые. Данный процесс называется rekeying. Время жизни (lifetime) SA может определяться временным промежутком (не более 24 часов) или объемом траффика.
В протоколе IKE версии 2 реализован ряд изменений:
-определен одним RFC
-протокол упрощен (убран ряд избыточных функций, таких как агрессивный режим, обмен групп (group exchange), аутентификация через публичные ключи)
-надежная передача сообщений
-дополнительная защита от DoS атак
-поддержка EAP (возможна аутентификация по Kerberos и Radius)
Данные в пакетах могут сжиматься перед шифрованием средствами протокола IP payload compression protocol (IPComp). Данные могут сжиматься как в одном, так и в двух направлениях.
Протокол ISAKMP используется для создания SA и управления ими. Обеспечивает только фреймворк для обмена ключами. Сам процесс обмена происходит независимо от ISAKMP.
Основные факторы, которые следует иметь ввиду при размещениий vpn-шлюза:
-производительность устройства (операции шифрования интенсивно используют процессор)
-проверка трафика (файрволлы и СОВ не могут проверять шифрованный трафик. следует размещать их таким образом, чтобы проверялся трафик после рашсифровки)
-трафик не защищенный IPSec (например если впн-шлюз располагается вне файрволла, следует убедиться, что расшифрованный трафик, проходящий между впн-шлюзом и файрволом не подвергается риску)
-отказоустойчивость
-NAT. Так как в процессе трансляции адресов меняется адрес источника в заголовке пакета, в результате чего пакет не проходит проврку целостности IPSec. Существуют следующие решения: 1. Транслировать адреса до применения IPSec 2. Инкапсулировать ESP-пакеты в UDP-датаграммы (т.е. использовать ESP в туннельном режиме, или транспортный режим ESP с протоколом L2TP).
Функция IKE, известная как IPSec NAT Traversal (NAT-T) позволяет IKE согласовывать использование UDP-инкапсуляции. Обе стороны сообщают о поддержке NAT-T, после чего производится обнаружение NAT (каждая сторона отправляет хэш своего сетевого адреса), другая сторона сравнивает этот хеш с хешем адреса в полученном пакете, определяяя таким образом использовался ли NAT при передаче пакета. После этого, IKE начинает использовать порт 4500 вместо 500, чтобы избежать конфликтов.
При выборе впн-клиента следует принимать во внимании вопрос разделенных (split) туннелей, когда клиент находится в публичной сети и трафик, идущий в сеть организации проходит через туннель, остальной трафик - через публичную сеть. Это может быть опасно, т.к. атакующий, подключившись к компьютеру клиента может попасть в локальную сеть организации. Отдельные программные продукты для установления впн-соединений могут предотвращать появление разделенных туннелей, а также отключать все сетевые интерфейсы, кроме того, через который устанавливается впн-соединение.
Аутентификация.
Аутентифиация в IPSec может происходить с помощью разделяемого ключа и электронных подписей.
Хотя разделяемый ключ проще в настройке, с ним возникает ряд сложностей: 1. Если одиному из хостов, имевших доступ ранее, следует его запретить, разделяемый ключ следует поменять у всех остальных хостов 2. Ключи следует периодически обновлять для уменьшения негативных последствий его возможной компреметации 3. Лицо получившее доступ к ключу в одной из точек подключения, может получить доступ также в одной или несокльких других точках.
Т.о. по соображениям масштабируемости и безопасности, разделяемый ключ следует использовать только для небольших групп устройств с известными адресами или небольшим набором адресов. Также разделяемый ключ не рекомендуется использовать, если хосты не имеют статического адреса (например удаленные работники).
Разделяемые ключи можно использовать на стадии внедрения и тестирования IPSec с последующей сменой метода аутентификации.
При использовании электронных сертификатов каждое устройство имеет идентифицирующий его сертификат (также могут использоваться сертификаты для пользователей). Два узла IPSec будут доверять друг другу, есть их сертификаты подписаны Certification Authority (CA), которым оба доверяют. Для управления сертификатами разворачивается публичная инфраструктура ключей (Public Key Infrastructure, PKI).
Хотя данный метод и является более надежным и масштабируемым, у него есть свои недостатки. При установлении соединения, должна проводиться проверка сертификата. За время проведение проверки сертификата сессия IKE может оборваться по тайм-ауту.
Т.к. при использовании цифровых подписей размер пакетов увеличивается, могут возникнуть проблемы с фрагментацией.
Фильтры пакетов (packet fileters)
Их целью является разделение трафика на нуждающийся и не нуждающийся в защите. По умолчанию защищается весь трафик, однако в некоторых случаях это нежелательно т.к. отрицательно влияет на производительность. Например, шифрование уже зашифрованного трафика является, по сути, тратой ресурсов. Для уже зашифрованного трафика имеет смысл отключать шифрование IPSec, оставляя только проверку целостности или просто пересылать без какой-либо защиты.
Некоторые типы трафика, например широковещательный и мультикаст трафик, несоввметсимы с IPSec.
Важные факторы при внедрении IPSec:
-Следует реализовать и поддерживать меры безопасности, дополняющие vpn: брандмауэры и антивирусы на конечных точках подключения, контроль "здоровья" конечных точек, ограничение доступа к vpn-шлюзам и т.д.
-время жизни SA. Для тестов можно выставлять кортокие (5-10 минут), в рабочих реализациях обычное время жизни IKE SA - 24 часа (86400 секунд), IPSec SA - 8 часов (28800 секунд). Важно, чтобы у пиров были одинаковые настройки времени жизни SA, т.к. некоторые реализации IPSec разрываюет IKE сессию, если пир предлагает время жизни более долгое, чем имеющееся в настройках.
-Фаза 1 IKE: везде, где возможно следует использовать main mode, т.к. предлагает более стойкую защиту.
-Группы диффи-хеллмана. Следует использовать настройки групп, соответсвующие совеременным стандартам. На 2014 год Cisco рекомендует группы 15 и 16 (3072-bit 4096-bit DH), либо 19 и 20 (256-bit and 384-bit ECDH). Следует учитывать производительноть оборудования при выборе групп Диффи-Хеллмана, т.к например группы 15, 16 могут не поддерживаться на аппаратном уровне, а обработка их на уровне ПО может перегружать процессор.
-Алгоритмы шифрования и аутентификации. Рекомендуется использовать как алгоритм шифрования так и алгоритм аутентификации. Рекомендация Cisco на 2014 год: AES 128 (AES-256 для секретной информации), SHA-1 (SHA 256 или SHA 384 для секретной информации).
-Для повышения уровня безопасности следует включать PFS. На этапе внедрения данную технологию можно не задействовать, но рекомендуется протестировать и запустить ее после того, как настроен базовый функционал IPSec.
-Реагирование на инциденты. Следует подготовить эффективный сценарий действия на случай компрометации IPSec ифраструктуры. Например, если скомпрометирован компьютер пользователя следует отозвать сертификат или удалить разделяемый ключ.
-Управление журналами. Следует собирать и хранить логи IPSec для того, чтобы устранять проблемы и расследовать инциденты.
-Резервирование.
-Совместимость оборудования и программного обеспечения. Не все реализации IPSec совметсимы друг с другом.
-Хранение разделяемых ключей. Ключи не должны храниться в текстовом виде. Доступ к файлам с ключами должны иметь только администраторы. На системе где хранятся ключи должне работать брандмауэр (желательно ИДС).
-Периодически в реализация IPSec находятся уязвимости. Следует отслеживать такую информацию и принмать меры к устранению "дыр".
-Шифрованый трафик может негативно сказаться на производительности сетевого оборудования (в т.ч. бранмауэров, ИДС, QoS)
-Управление решением. Следует документировать решение и изменения в нем, поддерживать актуальность программного обеспечения, обновлять настройки в соответсвии с современными требованиями к безопасности, следить за корректной работой и производительностью сетевого оборудования.
VPN-протоколы канального уровня
Т.к. эти протоколы работают на канальном уровне, с ними совместимы различные сетевые протоколы, такие как IP, IPX, NetBEUI. Большинство VPN-протоколов, включая IPSec, поддерживают только IP.
Наиболее распространенные VPN-протоколы канального уровня работают поверх PPP. PPP (Point-to-Point Protocol) предназначен для создания соединения между ДВУМЯ узлами и может инкапсулировать пакеты разных протоколов сетевого уровня и мультиплексировать их, используя одну линию.
PPP может обеспечивать шифрование и аутентификацию, но так как для этого используются алгоритмы, не обеспечивающие достаточного уровня защиты информации, используются другие протоколы канального уровня, предоставляющие более надежное шифрование и аутентификацию: PPTT, L2TP, L2F.
PPP в таких реализациях ТОЛЬКО ИНКАПСУЛИРУЕТ.
PPTP
Протокол, разработанный Майкрософт. Обеспечивает защищенный канал между клиентом и сервером. Использует IP протокол 47 (GRE) для передачи данных. ПОЗВОЛЯЕТ ТУННЕЛИРОВАТЬ PPP ЧЕРЕЗ IP СЕТИ. Используются собственный механизм шифрования (Microsoft Point-to-Point encryption, MPPE) и авторизации (PAP, CHAP, CHAPv2). На данный момент эти механизмы имеют известные уязвимости, соответственно использование для передачи конфиденциальных данных не рекомендуется.
L2F
Проприетарный протокол Cisco. Предназначен для шифрования трафика между сетевыми устройствами, например сервером доступа сервис-провайдера и ВПН-шлюзом организации. Пользователь подключается к серверу провайдера, сервер распознает пользовательский трафик, как требующий защиты, производите аутентификацию впн-шлюза организации и пользователя и обеспечивает защиту трафика между сервером и впн-шлюзом. При этом трафик между пользователем и серверов провайдера остается незащищенным.
L2TP
Протокол, разработанный IETF, призван объединить и модернизировать PPTP и L2F. Защищенные соединения устанавливаются между клиентом и сервером. Вместо GRE использует собственный туннельный протокол (UDP порт 1701). Поддерживает несколько сессий в одном туннеле. Помимо аутентификации PPP может использовать RADIUS и TACACS+. Может использовать IPSec для шифрования и управления ключами. Может работать не только через IP-сети (но и ATM, X.25, Frame Relay). Для аутентифиации данных используется HMAC MD5. Для взаимной аутентификации клиента и сервера используется разделяемый ключ или сертификаты. После того, как завершена аутентификация клиента и сервера происходит аутентификация пользователя и использованием одного из протоклов PPP (PAP, CHAP. при этом к моменту начала аутентификации пользователя соединение уже зашифровано, следовательно аутентификацию пользователя можно проводить даже с помощью PAP).
Преимущества L2TP+IPSec:
-Более надежная защита данных
-Более надежная аутентификация (как для уровне компьютера, так и на уровне пользователя)
-Может работать через сети отличные от IP
Преимущества PPTP:
-Не требует PKI или механизма управления разделяемыми ключами
-Можно использовать на компьютерах со стаыми ОС
-Может использоваться даже если клиент и сервер находятся за NAT-устройством (при условии, что сделаны соответствующие настройки NAT). Клиент и сервер L2TP могут располагаться за NAT-устройством только при условии что оба поддерживают NAT-T.
Обратить внимание: если не требуется туннелирование протоколов канального уровня, можно использоваться IPSec в туннельном режиме чтобы генерировать меньше overhead траффика (PPP и GRE заголовки).
Источники:
NIST Special Publication 800-77b Guide to IPsec VPNs Recommendations of the National Institute of Standards and Technology
Sheila Frankel, Karen Kent, Ryan Lewkowski, Angela D. Orebaugh, Ronald W. Ritchey, Steven R. Sharma
Рекомендации Cisco по выбору алгоритмов:
http://www.cisco.com/web/about/security/intelligence/nextgen_crypto.html
Презентация APNIC об IPSec:
http://www.youtube.com/watch?v=gnUIgSvx3OE
http://windowsitpro.com/networking/pptp-vs-l2tp
https://msdn.microsoft.com/en-us/library/bb742566.aspx
RFC:
4301 - the internet security architecture
4302 - AH
4303 - ESP
2048 - ISAKMP
5996 - IKEv2
4835 - cryptographic algorithm implementation for ESP and AH
1661 - The Point-to-Point Protocol (PPP)
2637 - Point-to-Point Tunneling Protocol, available at
2784 - Generic Routing Encapsulation (GRE)
Комментариев нет:
Отправить комментарий