IPSec широко используется для шифрования данных при передаче по незащищенным сетям. Однако для этого набора протоколов администраторы часто используют настройки, которые не обеспечивают требуемого уровня безопасности. Мы рассмотрим уязвимости IPSec pre-shared key, типичные ошибки при внедрении IPSec с аутентификацией PKI CA и другие нюансы, которые важно понимать при его использовании в корпоративной сети.

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

Для противодействия MitM-атакам в общем случае используется организация доверенных соединений с шифрованием трафика. Чаще всего это различные типы VPN, обеспечивающие защиту на разных уровнях сетевой модели OSI. К примеру, на сеансовом уровне применяется туннельный протокол PPTP, а на сетевом — набор протоколов IPSec. Мы рассмотрим последний в варианте Site-to-Site, так как он решает сразу несколько задач: позволяет подтверждать подлинность сетевых узлов, выполнять шифрование IP-пакетов и проверку их целостности.

 

Как устроен IPSec

В наборе IPSec все протоколы работают в связке друг с другом и в строгой очередности. Главный из них — это протокол потокового симметричного шифрования данных DES или AES. Это вторая фаза IPSec, которой предшествует первая — этап обмена сессионными ключами, происходящего по протоколу DH (Диффи — Хеллмана). Он сам по себе уязвим к MitM, из чего следует необходимость предварительной аутентификации сторон, которая достигается посредством протокола ISAKMP. Это ключевые этапы IPSec (промежуточных куда больше), каждый из которых влияет на итоговый уровень безопасности.

Важно понимать, что обмену ключами в IPSec предшествует установление общих атрибутов безопасности (SA — Security Association) между двумя сетевыми узлами по протоколу IKE (Internet Key Exchange). Эти атрибуты содержат указание на криптографический алгоритм и режим его использования, ключ шифрования трафика, а также различные служебные параметры соединения.

Дальше ключи в IPSec распределяются с использованием набора псевдослучайных чисел, соответствующих заданным условиям. Их называют группами Диффи — Хеллмана, или DH-Groups. Они основаны либо на возведении в степень по модулю (MODP — More Modular Exponential, см. RFC 3526), либо на эллиптических кривых (ECP — Elliptic Curve Groups, см. RFC 5903).

Наиболее популярные группы приводятся в секции 3.2 RFC 5114. Для удобства они имеют зарегистрированные в IANA порядковые номера, поэтому вместо сложной конструкции 2048-bit MODP Group with 256-bit Prime Order Subgroup можно использовать более короткую: DH-Group 24.

На практике в IPSec мы можем также использовать различные варианты DES и AES, их сочетания с разными хеш-функциями (от MD5 до SHA-512) и другими криптографическими примитивами. Например, использование алгоритма AES в режиме сцепления блоков шифртекста (СBC) описывает RFC 3602, а в режиме счетчика (CTR) — RFC 3686. Усовершенствованный алгоритм AES-CBC с использованием кода аутентификации сообщения (MAC) под названием AES-XCBC-MAC-96 описывает RFC 3566.

При использовании IPSec дополнительную безопасность на транспортном уровне обеспечивают протокол безопасности ESP (Encapsulating Security Payload) и применение аутентификационных заголовков AH (Authentication Header). Требования к их практической реализации описаны в RFC 4305.

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

 

Повышаем безопасность

На мой взгляд, если необходим действительно высокий уровень безопасности, то в стратегии обмена ключами IPSec нужно применять DH-Group 19 (256 ECP) и выше, AES с длиной ключа 256 бит, алгоритм проверки подлинности сообщений HMAC-SHA-512 плюс дополнительные меры, о чем будет сказано ниже.

Выбор режима AES зависит от решаемых задач и ограничений оборудования. В большинстве ситуаций достаточно классических CBC или CTR, но, если интересно, взгляни в сторону более продвинутых схем: CCM (CBC-MAC, она используется также в WPA2) и GCM (Galois/Counter Mode, счетчик с аутентификацией Галуа).

Интересно и то, что на 64-битных процессорах SHA-512 вычисляется быстрее, чем SHA-256, из-за использования в первом случае нативного 64-битного представления чисел. AES тоже работает быстрее DES на современном железе, поскольку аппаратное ускорение раундов шифрования AES интегрировано даже в простейшие чипы Intel и AMD.

 

Три кита IKE

Уже первая версия протокола IKE предлагает три вида аутентификации сторон: PSK (Pre-shared key, предопределенный ключ), RSA-Sig и RSA-Key. Из них PSK — наиболее простой в реализации, а потому и самый часто встречающийся на практике вариант.

Уязвимости IKE PSK довольно типичны. Во-первых, это используемый в качестве ключа словарный, короткий или простой по структуре набор символов, уязвимый к атакам по словарю и брутфорсу. Современные программы вроде Elcomsoft Distributed Password Recovery умеют проводить гибридные атаки, генерируя на основе словаря разные вариации. Поэтому пароли NImDA или nimdanimda уязвимы так же, как и просто nimda.

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

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

При апгрейде оборудования часто забывают сбрасывать настройки. Их просто клонируют, а старый маршрутизатор списывают и продают. Кто купит его, получит доступ к конфигурации корпоративной сети — читай, узнает SSID, PSK, доверенные MAC-адреса и много чего еще.

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

Продолжение доступно только участникам

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score! Подробнее

Вариант 2. Открой один материал

Заинтересовала статья, но нет возможности стать членом клуба «Xakep.ru»? Тогда этот вариант для тебя! Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.


Check Also

Изучаем ПЛК. Краткий гайд по поиску уязвимостей в промышленных контроллерах

Если ты думаешь, что контроллеры, которые ставят в зданиях и на заводах, защищены намного …

1 комментарий

  1. Аватар

    KitFisto

    22.05.2019 at 10:46

    Интересная статья. Спасибо!

Оставить мнение