Главная » Песочница » Безопасность IPSec

Безопасность IPSec

IPSec безопасность

Здравствуйте, друзья! Тема сегодняшней статьи IPSec безопасность. 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

На мой взгляд, если необходим действительно высокий уровень безопасности, то в стратегии обмена ключами 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 так же уязвим, как NImDA или nimdanimda.

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

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

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

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

MitM на IPSec с PSK

Если PSK стал известен хакеру, то дальнейшая атака выполняется примерно следующим образом. Предположим, что Алиса и Боб общаются через IPSec-туннель в незащищенной сети.

Алиса и Боб мило общаются по сети
Алиса и Боб мило общаются по сети

Ева хочет получить доступ к их переписке и отправлять Бобу фальшивые сообщения от имени Алисы, а также иметь возможность подделывать ответы Боба. Для этого между целевыми узлами сети она устанавливает два дополнительных маршрутизатора.

Ева образует нелюбовный треугольник
Ева образует нелюбовный треугольник

Этот вариант MitM-атаки по типу Evil clones проще, чем кажется. В случае проводных сетей ничто не мешает вклиниться «в разрыв», а у беспроводных на руку атакующей стороне играет мощность сигнала, затухающая с расстоянием. У фальшивой точки доступа она будет выше просто в силу более близкого расположения к цели. Поэтому роутеры Алисы и Боба охотнее соединятся с фейковыми маршрутизаторами посередине канала, чем друг с другом.

При установке IPSec-туннеля проверяются только PSK и IP-адрес. Благодаря известному PSK роутер хакера R3 смог выдать себя за легитимный R2 и терминировать IPSec-туннель на себе. Следующий фейковый роутер (R4) получит от него уже расшифрованный трафик. Он имитирует R1 Алисы для R2 Боба и отправляет последнему повторно зашифрованный (и уже опционально измененный) трафик. Между подконтрольными хакеру узлами R3 и R4 достаточно установить сниффер (например, Wireshark), чтобы читать и подменять пакеты по своему усмотрению.

Тут вся соль в инкапсуляции и декапсуляции IPsec на промежуточных узлах. Прикинувшись R2, зловредный роутер R3 обменивается с R1 сессионными ключами для потокового шифрования (неважно, DES или AES). Поэтому он без проблем декапсулирует и расшифровывает пакеты от R1. Дальше передает их в открытом виде R4, который зеркалирует схему: имитирует R1, генерирует ключи для R2 и отправляет ему зашифрованный инкапсулированный трафик от имени R1.

На первый взгляд, приведенная схема R1 — R3 — R4 — R2 вообще противоречит правилам построения сетей. Тут получаются две одинаковые IP-подсети в двух местах: между R1 и R3 и между R4 и R2. Если эту схему показать админу, то он, скорее всего, скажет, что это бред. Однако она работает — как в GNS3, так и на реальных роутерах.

Представленная топология была протестирована в сетевом программном эмуляторе GNS (Graphical Network Simulator 3) с алгоритмом DES и хеш-функцией MD5. Конфигурационные файлы для всех четырех роутеров доступны по ссылке.

MitM на IPSec с RSA-Sig

Если для аутентификации сторон вместо PSK в IPSec используется PKI CA (RSA-Sig), то доступ к файлу конфигурации не позволит выполнить описанную выше атаку. Система асимметричного шифрования RSA использует два ключа: public и secret, а секретный не хранится в конфигах… если только пара ключей не была сгенерирована с опцией exportable для обоих. Да, это типичная небрежность, серьезно понижающая уровень безопасности. Есть и другие тонкости практической реализации RSA-Sig, незнание которых снижает защиту до нуля.

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

К сожалению, во многих учебных пособиях (даже в базовом руководстве CCNP Security 300-209) в качестве примера приводится такая упрощенная схема внедрения, сводящая безопасность IPSec на нет.

Черный юмор ситуации в том, что данная конфигурация может пройти аудит безопасности, например PCI-DSS. Знаю это из практики. Аудитор спрашивает тебя, шифруются ли в вашей сети данные. Ты уверенно отвечаешь «Да!» и в подтверждение показываешь ему скриншоты, где указывается надежный протокол IPSec, да еще и с PKI CA. Он радостно ставит галочки в своем опроснике, и вы идете пить чай. Аудит успешно «пройден».

Можно ли выполнить для RSA-Sig атаку посредника, как для PSK? В отдельных случаях это даже проще сделать: хакеру понадобится только один «злой клон». Вот самая простая и часто встречающаяся топология, рекомендованная в руководствах: Алиса использует роутер А, Боб принимает ее трафик на своем роутере B. Аутентификацию PKI CA выполняет отдельный сервер.

Ничто не предвещало беды…
Ничто не предвещало беды…

Атакующая сторона добавляет в сеть свой роутер и присваивает ему MAC/IP-адрес роутера Боба. После этого хакер генерирует пару ключей и отправляет запрос на сервер для подписи публичного ключа (якобы нового, сгенерированного Бобом). В ответ он получает от сервера подписанный сертификат и устанавливает «защищенный» IPSec-туннель с Алисой от имени Боба.

…но тут пришла Ева и клонировала роутер Боба
…но тут пришла Ева и клонировала роутер Боба

Схема тестировалась также в эмуляторе GNS. Конфиги доступны по ссылкам:

Защита IPSec

Защита IPSec с PSK

Для противодействия MitM при реализации IPSec с PSK я рекомендую сделать следующие вещи.

1. Использовать длинный (от 8 до 63 байт) и сложный Pre-shared key. Допустимые символы: ASCII 0x20 — 0x7e (то есть цифры + заглавные и строчные буквы латинского алфавита + набираемые с клавиатуры знаки).

2. В маршрутизаторе и файрволе Cisco использовать команду no service password-recovery. В этом случае при попытке загрузиться в режиме ROM Monitor (rommon) конфигурационный файл (хранящийся со всеми паролями в startup-config) будет стерт. Злоумышленник не сможет его использовать, прервав загрузку циски и сменив ей 16-битный конфигурационный регистр.

3. Используй при создании учетных записей и их сохранении в Cisco Router Password Storage алгоритм scrypt. Он наиболее стойкий к брутфорсу, поскольку каждая итерация занимает уйму процессорного времени. Чтобы выключить его, просто введи в консоли

Теперь следующей командой ты можешь создавать аккаунты, защищенные scrypt:

Подробнее читай здесь.

4. Используй межсетевые экраны от Palo Alto Networks вместо Juniper SRX. В базовой настройке Juniper SRX, получив физический доступ и не зная пароля, можно загрузить конфигурацию по умолчанию (factory defaults). После этого ты увидишь пять или более ранних конфигураций, а потом сможешь снова загрузить последнюю рабочую. Эта операция пройдет полностью бесследно. В логах останется только факт перезагрузки.

Пароли и PSK в конфигах там хоть и зашифрованы, но допускают подстановку копипастой. То есть их можно использовать, даже не подбирая. У МСЭ Palo Alto Networks, если загрузить factory defaults, рабочий конфиг автоматически сотрется. Значит, они лучше защищены от инсайдерских атак, подразумевающих физический доступ к оборудованию.

5. В политике безопасности советую указать обязательную периодическую смену всех PSK и почаще. Только не автоматическую смену, а запрос на ее выполнение вручную.

6. Защитить места хранения резервных копий конфигурационных файлов.

7. Перейти c PSK на RSA-Key.

Защита IPSec с PKI CA

Чтобы защититься от MitM при использовании IPSec с RSA-Sig, советую выполнить перечисленные ниже условия.

1. При генерации пары RSA-ключей не использовать опцию exportable.

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

3. На CA-сервере должна быть отключена функция grant auto. Администратор должен точно удостовериться в том, чей именно сертификат он подписывает. В этом случае автоматического перевыпуска сертификатов не будет.

4. В политике безопасности укажи обязательную периодическую регенерацию RSA-ключей и перевыпуск сертификатов.

5. Просто перейди на RSA-Key!

Выводы

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *