Security: IPSec VPN (Theory, Cisco implementations: gre over ipsec, cryptomaps, ezvpn, flexvpn, getvpn)

IPSEC

  • Все статьи про VPN
  • Хорошая преза на основе Cisco Learning Academy
  • Базовая настройка IPsec и GRE есть уже даже в CCNA R&S (enterprise)
  • IPSec используется OSPF/EIGRP для IPv6 в качестве замены md5
  • IPSec использует поточные алгоритмы шифрования
  • IPSec очень широко используется в enterprise, ISP, mobile решениях
  • Уязвим IPsec только IPSec IKEv1 в Aggressive Mode (поэтому лучше использовать MAIN Mode), уязвимость состоит в том, что существует возможность подбора PSK ключа при перехвате трафика Phase 1 посредством инструментов IKE-scan, PSK-crack, Cain и таким образом можно получить доступ к туннелю. В случае действительной необходимости использования Aggressive Mode рекомендуется использовать сертификаты, дополнительную аутентификацию XAUTH.
  • IPSec нативно не поддерживает NAT – AH и ESP L3 протоколы (инкапсулируются напрямую в IP) без L4-портовой информации в нативном исполнении:
    • Для NAT есть разные костыли у роутеров (IPSec/VPN passthrough), которые идентифицируют IPSec в проходящих пакетах (на основе значений SPI) и делают на его основе трансляцию через NAT (иногда даже успешно, например,  на Cisco ASA такая функция есть). В итоге не требуется использовать версии протоколов ESP/AH, работающие через IPSec (UDP 500, UDP 4500) и “платить” за дополнительный оверхед.
    • Так же для работы через NAT: для management session IKE v1/v2 (ISAKMP SA) при шифровании IPSec на основе ESP (не AH, AH не поддерживает NAT-T) есть версия IPSec (она чаще всего на практике и используется) в которой IKE сообщения вкладываются в UDP 500 (так же бывают реализации на базе TCP 500).
    • Так же для работы через NAT: для data session ESP (IPSec SA) есть версия IPSec NAT-T в которой ESP сообщения вкладываются в UDP 4500.
  • Wireshark может расшифровать зашифрованные данные, если дать ему нужную ключевую информацию (например, дав ему пароль от Wi-Fi для WEP/WPA сети, IPsec, SSL/TLS-сессии).

IPSec (сокращение от Internet Protocol Security) — набор протоколов для обеспечения защиты данных, передаваемых по межсетевому протоколу IP, позволяет осуществлять подтверждение подлинности и/или шифрование IP-пакетов. IPsec также включает в себя протоколы для защищённого обмена ключами в сети Интернет. В основном, применяется для организации vpn-соединений (как site-to-site, так и remote-access).

В оригинале IPv6 требовал обязательной поддержки IPsec для полного соответствия требованиям IPv6 (поэтому многие CPE роутеры были только IPv6 ready), в последующем это требование убрали из обязательных.

IPsec работает путем шифрования и инкапсуляции оригинального IP пакета в пакет IPsec.

 

IPSEC framework

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

  • Internet Key Exchange (IKE) –  это основа IPSec, именно IKE обеспечивает согласование протоколов и безопасный обмен ключами. IKE базируется на ISAKMP. Бывает первой и второй версии – IKEv1 (RFC 2409), IKEv2 (RFC 5996). В IKEv1 эта сессия может быть установлена в двух режимах – main и aggressive. Подробнее о версиях можно прочитать ниже в “IKEv1 & IKEv2”
  • Authentication Header (AH) – L3 протокол, обеспечивает целостность передаваемых данных, аутентификацию источника информации и replay protection.
  • Encapsulating Security Payload (ESP) – L3 протокол, обеспечивает шифрование, целостность передаваемых данных, аутентификацию источника информации и repay protection. ESP так же как и AH имеет разную последовательность инкапсуляции своего заголовка, в зависимости от типа IPsec.
  • DES, 3DES, AES – шифрование данных
  • MD5, SHA – проверка целостности на основе хэша (подробнее в хешировании). IPSec использует как MD5 хэш-алгоритм (128 бит на выходе), так и SHA-1 (160 бит на выходе), а для того чтобы не делать два разных формата пакета для каждого хэш-алгоритма используются только последние 96 бит полученного алгоритмом хэша.
  • Diffie-Hellman (DH) – алгоритм обмена ключами (подробнее в шифровании > несимметричные алгоритмы).
  • RSA-signature (сертификат)/PSK (пароль) – аутентификация.
  • HMAC – хэширование ключей аутентификации.
Режимы шифрования IPSec

Независимо от использования AH/ESP IPsec может использовать два разных режима шифрования:

  • Туннельный (tunnel mode) – шифруется и payload и IP header, IP packet весь инкапсулируется в новый IP пакет. Режим по умолчанию в большинстве реализаций IPsec Cisco. Часто используется для защиты хостов, которые находятся за VPN.
Tunnel mode - protects the entire IP packet.
  • Транспортный (transport mode; используется, например, в Windows или в GRE over IPSEC) – шифруется только payload оригинального пакета, IP header сохраняется оригинальный, но используется authentication header, который включает hash от данных IP пакета (включая header IP, transport, application data). Это защищает от подмены данных (включая NAT/PAT), включая данные не зашифрованного IP header. Типичное применение Transport mode – GRE over IPsec.
Transport mode - protects upper layer protocols, such as UDP and TCP.

IKEv1 & IKEv2

Отличия IKEv2 от IKEv1. Если вкратце – IKEv2 лучше и проще, поддерживает из коробки RA VPN (remote access), NAT, DPD, DoS protection.

  • улучшение/упрощение функции обмена ключами и аутентификации
  • исправление уязвимостей в IKEv1
  • поддержка самых новых протоколов шифрования
  • встроенные возможности anti-DoS
  • IKEv2 поддерживает использование EAP (Extensible Authentication Protocol), например, для использования IPSec на базе IKEv2 для задачи remote access VPN
  • IKEv2 и IKEv1 несовместимы

Установка защищенного соединения IPsec независимо от версии IKE (IKEv1, IKEv2) происходит два этапа – фаза I и фаза II. За две ключевые фазы установки IPSEC туннеля/сессии отвечает Internet Key Exchange (IKE) протокол. Пример разбора работы фаз ниже и в документации Huawei.

  • В первой фазе происходит согласование IKE SA (Security Associations), при NAT-T работает на порту UDP 500. 
    • согласование методов шифрования/хеширования/групп DH/аутентификации (proposal-choice; 1-2 на слайде ниже)
    • генерация и обмен ключевой информацией по алгоритму Diffie-Hellman для формирования SKEYID (строка, полученная на основе secret material) – клиенты аутентифицируют друг друга по PSK ключу без передачи непосредственно ключей PSK, а nonce к которому применяется PSK и сравнивается между сторонами; 3-4 на слайде ниже
    • передается информация о ID устройств и проверяется на противоположных сторонах в зашифрованном виде (ключи шифрования сформированы на основе SKEYID), защищенное соединение для установки второй фазы установлено (5-6 на слайде ниже)
    • IKEv1 only: Фаза может происходить либо в Main Mode, либо в Aggressive Mode.
      • Main Mode является более безопасным т.к. в его случае шифруются все сообщения, тогда как в Aggressive Mode не шифруется идентификатор сайта. Обычно используется для site-to-site.
      • Aggressive mode используется в случае если на VPN концентраторе не прописываются в явном виде IP адреса удаленных точек (т.е. используется адрес по типу 0.0.0.0 разрешающий все соединения) или на удаленных адресах есть NAT трансляция.
  • Во второй фазе происходит согласование IPSec (IKEv1) или Child (IKEv2) SA (Security Associations), при NAT-T работает на порту UDP 4500. Так же фаза известна как “quick mode”, ipsec proposal с использованием transform set. Предыдущая фаза (ISAKMP, IKE ISA) обеспечивает защиту IPSec SA потому что весь payload кроме ISAKMP header шифруется. Одно согласованное IPSec SA всегда включает две security associations – входящее и исходящее. Обеим ассоциациям присваивается уникальное значение SPI (security parameter index). Опционально в этой фазе передается информация о PFS (perfect forward secrecy, подробнее выше) и может дополнительная информация при использовании Child SA (IKEv2).

Опционально может так же быть фаза I.5. в которой может происходить дополнительная аутентификация – например, для задачи решения Remote Access VPN с использованием IKEv1. XAUTH и назначение IP адреса туннельному интерфейсу Mode Config.

 

Сравнение IKEv1 с IKEv2

взято полностью отсюда.

IKEv1 IKEv2 (SIMPLE and RELIABLE!)
IPsec SA Child SA (Changed)
Exchange modes:

  • Main mode
  • Aggressive mode
 Only one exchange procedure is defined.
Exchange modes were obsoleted.
Exchanged messages to establish VPN.

  • Main mode: 9 messages
  • Aggressive mode: 6 messages
 Only 4 messages.
Authentication methods ( 4 methods ):

  • Pre-Shared Key (PSK)
  • Digital Signature (RSA-Sig)
  • Public Key Encryption
  • Revised Mode of Public key Encryption
 Only 2 methods:

  • Pre-Shared Key (PSK)
  • Digital Signature (RSA-Sig)
Both peers must use the same authentication method. Each peer can use a different authentication method (Asymmetrical authentication).
(e.g. Initiator: PSK and Responder: RSA-Sig)
Traffic selector:

  • Only a combination of a source IP range, a destination IP range, a source port and a destination port is allowed per IPsec SA.
  • Exact agreement of the traffic selector between peers is required.
  • Multiple combinations of a source IP range, a destination IP range, a source port range and a destination port range are allowed per Child SA. Of course, IPv4 and IPv6 addresses can be configured for the same Child SA.
  • Narrowing traffic selectors between peers is allowed.
Lifetime for SAs:
Agreement between peers is required.		 NOT negotiated. Each peer can delete SAs anytime by exchanging DELETE payloads.
Multi-hosting:
Basically, NOT supported.		 Supported by using multiple IDs on a single IP address and port pair.
Rekeying:
NOT defined.		 Defined.
NAT Traversal:
Defined as an extension.		 Supported by default.
Dead Peer Detection / Keep-alive for SAs:
Defined as an extension.		 Supported by default.
Remote Access VPN:
NOT defined. Supported by vender-specific implementations:

  • Mode config
  • XAUTH
 Supported by default:

  • Extensible Authentication Protocol (EAP)
  • User authentication over EAP is associated with IKE’s authentication.
  • Configuration payload (CP)
Multi-homing:
Basically, NOT supported.		 Supported by MOBIKE (IKEv2 Mobility and Multihoming Protocol: RFC 4555).
Mobile Clients:
Basically, NOT supported.		 Supported by MOBIKE (IKEv2 Mobility and Multihoming Protocol: RFC 4555).
DoS protections:
Basically, NOT supported.
  • Anti-replay function is supported.
  • ‘Cookies’ is supported for mitigating flooding attacks.
  • Many vulnerabilities in IKEv1 were fixed.
Less reliable than IKEv2. More reliable.

  • All message types are defined as Request and Response pairs.
  • A procedure to delete SAs is defined.
  • A procedure to retransmit a message is defined.
Extensions are very poor. Useful extentions in actual network environment.

  • “Redirect Mechanism for IKEv2 (RFC5685)”
  • “IKEv2 Session Resumption (RFC5723)”
  • “An Extension for EAP-Only Authentication in IKEv2 (RFC5998)”
  • “Protocol Support for High Availability of IKEv2/IPsec (RFC6311)”
  • “A Quick Crash Detection Method for the Internet Key Exchange Protocol (IKE) (RFC6290)”
etc.

See the IETF ipsecme-WG’s web page.

 

 

GRE over IPSec

Зачем нужны туннели GRE over IPSec: GRE поддерживает передачу мультикастовых (и бродкастовых) сообщений и разных L3 протоколов через GRE туннель, но не поддерживает шифрование. Это поддерживается в силу того, что роутер рассматривает gre-туннельные интерфейсы как подвид Serial. В тоже время IPSEC не поддерживает передачу мультикаста и других протоколов кроме IP. Поэтому использование GRE over IPSEC является нормальной практикой для предприятий – GRE позволяет работать routing протоколам через туннель, а IPSEC позволяет зашифровывать весь трафик GRE, обеспечивая безопасность. Так же в таком сценарии возможен полный отказ от GRE, если использовать BGP. т.к. он работает не используя мультикаст, но это уже другая история.

GRE over IPSec – over означает, что именно GRE инкапсулируется в IPSec, а не наоборот. Таким образом, GRE туннель работает внутри IPSEC.

 

 

IPSec Traditional site-to-site based on crypto-maps

Бывает двух типов:

    • static – на пирах настраивается статически адресация второй стороны
    • dynamic – на одной из сторон не требуется адресация второй стороны (hub-spoke, BRAS)

Основные шаги по настройке IPSec (static crypto-maps)

Примеры конфига есть тут h4cker.org/github.

Очень хорошее описание (мое же :D) и пример конфига создания site to site IPSec туннеля без GRE.

  1. Создаем ACL по выборке трафика, который будет шифроваться
  2. Для связи с удаленным хостом настраиваем ISAKMP policy (ipsec phase 1) и симметричный ключ до remote site (при настройке ISAMP policy как PSK pre-share)
  3. Для шифрования настраиваем transform-set и crypto map
    1. transform-set (ipsec phase 2) – определяем как шифруется трафик (AES, SHA, HMAC)
    2. crypto map – определяем какой трафик шифруется (определяем адрес remote site, ACL по выборке трафика и transform-set)
  4. Применяем crypto map на интерфейс, через который доступен remote site. Это может быть как физический интерфейс, так и туннельный.

Пример конфига IPSec + GRE.

  1. Определить tunnel endpoint интерфейс (интерфейс, на который ставится туннель). Чаще всего это loopback роутера.
  2. Создать GRE-туннель (gre tunnel interfaces). Туннельный интерфейс переходит в UP/UP как только будет сконфигурированы tunnel source/destination + будет маршрут в таблице маршрутизации до tunnel destination (сойдет даже default route, tunnel destination не обязательно должен даже пигноваться (GNS)).

3. Добавить туннельную сетку в процесс маршрутизации, чтобы начался обмен маршрутными сообщениями

4. Сконфигрурировать IPSEC и отдать трафик GRE в crypto access-list, для шифрования его посредством IPSEC

      • CRYPTOMAP GRE over IPSEC туннеля должен иметь три разрешающих ACL: GRE, ISAKMP, ESP

      • CRYPTO-шифрование GRE over IPSEC туннеля и TUNNEL destination должны ставится на физ. адрес, а не на tunnel адрес соседа

 

EZVPN

Старое решение Cisco на базе IPSec. Legacy продукт Cisco, клиенты были hardware (в основном) железками, подключающимися к site (remote access), полагался в своей работе на ipsec crypto-maps.

 

FLEXVPN

Основной кейс использования FlexVPN это site-to-site IKEv2, но возможно использование и для remote access. Топология site-to-site очень похожа на DMVPN – VPN туннели между hub & spoke always up, туннели между spoke динамически (on-demand) инициализируются. При этом в отличии от DMVPN FlexVPN не полагается на multipoint mGRE интерфейсы в своей работе.

Ключевые особенности FlexVPN

  • IKEv2 решение основанное на стандарте
    • может работать не только с решениями Cisco IKEv2
    • поддерживает фичи IKEv2, например
      • Configuration exchange
      • IKEv2 redirect for server load balancing
      • Cookie challenge for DoS mitigation
      • NAT traversal
      • IKEv2 fragmentation implementation
  • FlexVPN поддерживает проприетарные Cisco фичи IKE, напр.
    • IKEv2 call admission control
    • Session deletion on certificate expiry
    • Revocation to all supported VPN topologies
  • Поддерживает разные VPN топологии – point-to-point, remote-access, hub-and-spoke, dynamic mesh, включая возможность задания политик на пользователя или пира. Все эти настройки (и show команды в последующем) осуществляются из CLI с понятной единой (unified) логикой в рамка гибкой конфигурации FlexVPN.
  • FlexVPN поддерживает маршрутизацию поверх создаваемых туннелей
  • Поддерживает интеграцию с Cisco IOS AAA инфраструктурой
  • Поддерживает GRE и native IPsec инкапсуляцию, обнаруживая инкапсулированный протокол
  • Поддерживает работу как с IPv4, так и с IPv6 как на overlay, так и на underlay.

Процесс аутентификации клиента во FlexVPN

После локальной (на FlexVPN сервере) и удаленной (на EAP/RADIUS сервере) аутентификации происходит mutual authentication между IKEv2 client и FlexVPN server:

  • Метод локальной аутентификации должен быть на основе сертификата. FlexVPN сервер до проведения remote EAP аутентификации аутентифицирует клиентов (EAP supplicant) локально используя digital certificate-based метод аутентификации. Не поддерживается локальная аутентификация на базе EAP. (предложение ниже к удаленной аутентификации, но слайды сделаны плохо и это на одном слайде) FlexVPN сервер нуждается во внешнем сервере, к которому он будет обращаться для перенаправления EAP сообщений (pass-through authenticator) между EAP/Radius сервером (authentication server) и IKEv2 клиентами (EAP supplicants)
  • Для аутентификации удаленных подключений FlexVPN поддерживает только EAP, с указанием удаленного EAP/Radius сервера для аутентификации. EAP сообщения между IKEv2 client (EAP supplicant) и FlexVPN server передаются в IKE EAP payload и транспортируются посредством IKE auth request/response сообщений.

 

Пример конфига FlexVPN

В примере два роутера (один IKEv2 клиент, второй FlexVPN сервер) и радиус сервер.

  • Настройка radius (EAP) server
  • Настройка IKEv2 profile
  • На клиенте обязательна настройка уникального локального identity (identity local) и симметричного PSK ключа для аутентификации на FlexVPN server (??? А где сертификат, видимо можно и PSK – второй конфиг сервера это отражает ikev2 authentication local/remote pre-share)

 

Get VPN

Примеры конфигураций GETVPN h4cker.org/github.

Get VPN – Group Encrypted Transport VPN. MPLS + PKI site-to-site VPN.

В примере CE MPLS роутеры являются членами группы, подключенными к провайдерским PE MPLS роутерам.

GetVPN позволяет защитить ip unicast/multicast трафик в mpls сети. GETVPN позволяет роутеру применить шифрование на любой IP multicast/unicast трафик без использования туннелей (их не нужно создавать). GETVPN позволяет шифровать трафик без туннелей и иметь full-mesh connectivity в сети, стандартную маршрутизацию пакетов и QoS.

Члены группы (CE) регистрируются на ключевом сервере (KS) для получения SA, которые необходимы для взаимодействия внутри группы.
Члены группы передают групповой ID на KS для получения необходимых политик и ключей для данной группы. Эти ключи периодически обновляются. Обновление происходит до истечения текущего IPSec SA, что в итоге приводит к отсутствию потерь трафика во время обновления ключей.

Работает GETVPN на основе большого пула технологий/протоколов.

  • G-IKEv2 – проприетарный протокол GetVPN IKE version 2 реализация
  • GDOI – Group/ISAKMP Domain Of Interpretation, group keying (key management) protocol GDOI. Протокол группового управления ключевой информацией, работает совместно с IPsec. Описан в RFC 6407 (ранее RFC 3547). GDOI используется между членом группы и контроллером группы/ключевым сервером (GCKS – group controller or key server). Результатом их работы является установка Security Association между авторизованными членами группы.
  • Key Servers (KSs) – Key server создает и поддерживает ключи для группы, отвечает за (ключи лол) за регистрацию новых членов групп и отправку им ключевой информации, за переотправления (rekeying) ключевой информации.
    • регистрирует новых членов группы, в момент регистрации проверяет group id и только если id валидный, тогда сервер отправляет SA политику члену группы и соответствующие ключи (ключи отправляются после подтверждения членом группы того, что он может обработать полученную политику). Во время процедуры регистрации нового члена группы ключевой сервер загружает политики и ключи новому члену группы. Причем процедура регистрации может происходить в любое время и ключи/политики будут загружены самые актуальные на текущий момент.
    • rekeying (rekey mechanism) до того, как существующие ключи истекут – key server отправляет rekey сообщения, если IPsec SA заэкспайрится или если политика изменяется на ключевом сервере; rekey сообщения retransmit’ятся в случае потерь. GETVPN использует multicast rekeying в своей работе. multicast rekeying GETVPN основан на GDOI и описан в RFC 3547 (замещен RFC 6407).
    • Два типа ключей, которые члены группы могут получить от ключевого сервера
      • Key Encryption Key (KEK) – шифрует rekey message
      • Traffic Encryption Key (TEK) – является IPsec SA, который члены группы используют для шифрования трафика
  • Cooperative (COOP) KSs
  • Group members (GMs)
  • IP tunnel header preservation
  • Group security association
  • Time-based anti-replay (TBAR)

 

 

Troubleshooting IPSec tunnels

Разные тулзы могут пригодится при траблшутинге:

  • show commands & syslog messages
  • event-trace monitoring (бинарные логи внутри системы)
  • debug commands
show crypto isakmp sa # legacy ikev1
show crypto ikev2 sa |detailed| # ikev2
show crypto ikev2 session
show crypto ikev2 stats

debug crypto isakmp # legacy ilev1
debug crypto ikev2 # ikev2
debug crypto ikev2 internal # low level info about ipsec engine
debug radius authentication # auth problems between router - radius
debug crypto ipsec # debug phase 2 communication problems

 

 

Leave a Reply