для чего нужен ipsec
IPSec всемогущий
История вопроса
Изначально VPN планировался только для организации канала между мини-роутером родителей и домашним «подкроватным» сервером, по совместительству выступающим в роли маршрутизатора.
Спустя небольшой промежуток времени к этой компании из двух устройств добавился Keenetic.
Но единожды начав, остановиться оказалось сложно, и вскоре на схеме появились телефоны и ноутбук, которым захотелось скрыться от всевидящего рекламного ока MT_Free и прочих нешифрованных WiFi-сетей.
Потом у всеми любимого РКН наконец-то окреп банхаммер, которым он несказанно полюбил прилюдно размахивать во все стороны, и для нейтрализации его заботы о простых смертных пришлось поддержать иностранный IT-сектор приобрести VPS за рубежом.
К тому же некоей гражданке, внешне напоминающей Шапокляк, всюду бегающей со своим ридикюлем Пакетом и, вероятно, считающей что «Кто людям помогает — тот тратит время зря. Хорошими делами прославиться нельзя», захотелось тайком подглядывать в чужой трафик и брать его на карандаш. Придется тоже защищаться от такой непрошенной любви и VPN в данном случае именно то, что доктор прописал.
Подведем небольшой итог. Нужно было подобрать решение, которое в идеале способно закрыть сразу несколько поставленных задач:
Обзор существующих решений
Коротко пройдемся по тому что есть сейчас:
Дедушка Ленин всех протоколов. Умер, «разложился на плесень и на липовый мёд».
Кто-то, кроме одного провайдера, это использует?
Проект развивается. Активно пилится. Легко создать туннель между двумя пирами, имеющими статический IP. В остальных случаях на помощь всегда готовы придти костыли, велосипеды с квадратными колёсами и синяя изолента, но это не наш путь.
Приступаем к настройке
Определившись с решением приступаем к настройке. Схема сети в моем случае имеет следующий вид (убрал под спойлер)
ipsecgw.example.com — домашний сервер, являющийся центром сети. Внешний IP 1.1.1.1. Внутренняя сеть 10.0.0.0/23 и еще один адрес 10.255.255.1/30 для установки приватной BGP-сессии с VPS;
mama — Linux-роутер на базе маленького беззвучного неттопа, установленный у родителей. Интернет-провайдер выдает динамический IP-адрес. Внутренняя сеть 10.0.3.0/24;
keenetic — маршрутизатор Keenetic с установленным модулем IPSec. Интернет-провайдер выдает динамический IP-адрес. Внутренняя сеть 10.0.4.0/24;
road-warriors — переносные устройства, подключающиеся из недоверенных сетей. Адреса клиентам выдаются динамически при подключении из внутренного пула (10.1.1.0/24);
rkn.example.com — VPS вне юрисдикции уважаемого РКН. Внешний IP — 5.5.5.5, внутренний адрес 10.255.255.2/30 для установки приватной BGP-сессии.
Первый шаг. От простого к сложному: туннели с использованием pre-shared keys (PSK)
На обоих Linux-box устанавливаем необходимые пакеты:
На обоих хостах открываем порты 500/udp, 4500/udp и разрешаем прохождение протокола ESP.
Правим файл /etc/strongswan/ipsec.secrects (на стороне хоста ipsecgw.example.com) и вносим следующую строку:
На второй стороне аналогично:
В данном случае в качестве ID выступает вымышленный адрес элестронной почты. Больше информации можно подчерпнуть на официальной вики.
Секреты сохранены, движемся дальше.
На хосте ipsecgw.example.com редактируем файл /etc/strongswan/ipsec.conf:
Аналогично редактируем на удаленном пире /etc/strongswan/ipsec.conf:
Если сравнить конфиги, то можно увидеть что они почти зеркальные, перекрёстно поменяны местами только определения пиров.
Директива auto = route заставляет charon установить ловушку для трафика, подпадающего в заданные директивами left/rightsubnet (traffic selectors). Согласование параметров туннеля и обмен ключами начнутся немедленно после появления трафика, попадающего под заданные условия.
На сервере ipsecgw.example.com в настройках firewall запрещаем маскарадинг для сети 10.0.3.0/24. Разрешаем форвардинг пакетов между 10.0.0.0/23 и 10.0.3.0/24 и наоборот. На удаленном узле выполняем аналогичные настройки, запретив маскарадинг для сети 10.0.0.0/23 и настроив форвардинг.
Рестартуем strongswan на обоих серверах и пробуем выполнить ping центрального узла:
Нелишним будет так же убедиться что в файле /etc/strongswan/strongswan.d/charon.conf на всех пирах параметр make_before_break установлен в значение yes. В данном случае демон charon, обслуживающий протокол IKEv2, при выполнении процедуры смены ключей не будет удалять текущую security association, а сперва создаст новую.
Шаг второй. Появление Keenetic
Приятной неожиданностью оказался встроенный IPSec VPN в официальной прошивке Keenetic. Для его активации достаточно перейти в Настройки компонентов KeeneticOS и добавить пакет IPSec VPN.
Готовим настройки на центральном узле, для этого:
Правим /etc/strongswan/ipsec.secrects и добавляем PSK для нового пира:
Правим /etc/strongswan/ipsec.conf и добавляем в конец еще одно соединение:
Со стороны Keenetic настройка выполняется в WebUI по пути: Интернет → Подключения →
Другие подключения. Всё довольно просто.
Если планируется через тоннель гонять существенные объемы трафика, то можно попробовать включить аппаратное ускорение, которое поддерживается многими моделями. Включается командой crypto engine hardware в CLI. Для отключения и обработки процессов шифрования и хеширования при помощи инструкций CPU общего назначения — crypto engine software
После сохранения настроек рестрартуем strongswan и даём подумать полминуты Keenetic-у. После чего в терминале видим успешную установку соединения:
Шаг третий. Защищаем мобильные устройства
После чтения стопки мануалов и кучи статей решено было остановиться на связке бесплатного сертификата от Let’s Encrypt для проверки подлинности сервера и классической авторизации по логину-паролю для клиентов. Тем самым мы избавляемся от необходимости поддерживать собственную PKI-инфраструктуру, следить за сроком истечения сертификатов и проводить лишние телодвижения с мобильными устройствами, устанавливая самоподписанные сертификаты в список доверенных.
Устанавливаем недостающие пакеты:
Получаем standalone сертификат (не забываем предварительно открыть 80/tcp в настройках iptables):
После того как certbot завершил свою работу мы должны научить Strongswan видеть наш сертификат:
Перезапускаем Strongswan и при вызове sudo strongswan listcerts мы должны видеть информацию о сертификате:
После чего описываем новое соединение в ipsec.conf:
Не забываем отредактировать файл /etc/sysconfig/certbot указав, что обновлять сертификат тоже будем как standalone, внеся в него CERTBOT_ARGS=»—standalone».
Так же не забываем включить таймер certbot-renew.timer и установить хук для перезапуска Strongswan в случае выдачи нового сертификата. Для этого либо размещаем простенький bash-скрипт в /etc/letsencrypt/renewal-hooks/deploy/, либо еще раз редактируем файл /etc/sysconfig/certbot.
Перезапускаем Strongswan, включаем в iptables маскарадинг для сети 10.1.1.0/24 и переходим к настройке мобильных устройств.
Android
Устанавливем из Google Play приложение Strongswan.
Запускаем и создаем новый
Сохраняем профиль, подключаемся и, спустя секунду, можем не переживать о том, что кто-то сможет подсматривать за нами.
Windows
Windows актуальных версий приятно удивил. Вся настройка нового VPN происходит путем вызова двух командлетов PowerShell:
И еще одного, в случае если Strongswan настроен на выдачу клиентам IPv6 адреса (да, он это тоже умеет):
Часть четвертая, финальная. Прорубаем окно в Европу
Насмотревшись провайдерских заглушек «Сайт заблокирован по решению левой пятки пятого зампрокурора деревни Трудовые Мозоли Богозабытского уезда» появилась и жила себе одна маленькая неприметная VPS (с благозвучным доменным именем rkn.example.com) в тысяче километров от обезьянок, любящих размахивать банхаммером и блокировать сети размером /16 за раз. И крутилось на этой маленькой VPS прекрасное творение коллег из NIC.CZ под названием BIRD. Птичка первой версии постоянно умирала в панике от активности обезьянок с дубинками, забанивших на пике своей трудовой деятельности почти 4% интернета, уходя в глубокую задумчивость при реконфиге, поэтому была обновлена до версии 2.0.7. Если читателям будет интересно — опубликую статью по переходу с BIRD на BIRD2, в котором кардинально изменился формат конфига, но работать новая вервия стала намного быстрее и нет проблем с реконфигом при большом количестве маршрутов. А раз у нас используется протокол динамической маршрутизации, то должен быть и сетевой интерфейс, через который нужно роутить трафик. По умолчанию IPSec интерфейсов не создает, но за счет его гибкости мы можем воспользоваться классическими GRE-туннелями, которые и будем защищать в дальнейшем. В качестве бонуса — хосты ipsecgw.example.com и rkn.example.com будут аутентифицировать друга друга, используя самообновляемые сертификаты Lets Encrypt. Никаких PSK, только сертификаты, только хардкор, безопасности много не бывает.
Считаем что VPS подготовлена, Strongswan и Certbot уже установлены.
На хосте ipsecgw.example.com (его IP — 1.1.1.1) описываем новый интерфейс gif0:
Зеркально на хосте vps.example.com (его IP — 5.5.5.5):
Поднимаем интерфейсы, но поскольку в iptables нет правила, разрешающего GRE-протокол, трафик ходить не будет (что нам и надо, поскольку внутри GRE нет никакой защиты от любителей всяких законодательных «пакетов»).
Готовим VPS
Первым делом получаем еще один сертификат на доменное имя rkn.example.com. Создаем симлинки в /etc/strongswan/ipsec.d как описано в предыдущем разделе.
Правим ipsec.secrets, внося в него единственную строку:
На стороне хоста ipsecgw.example.com тоже добавляем в ipsec.conf в секцию setup параметр strictcrlpolicy = yes, включающий строгую проверку CRL. И описываем еще одно соединение:
Конфиги почти зеркальные. Внимательный читатель мог сам уже обратить внимание на пару моментов:
/rkn.example.com.pem, после чего при помощи scp перекрестно копируем их между серверами в расположения, указаные в конфиге
Не забываем настроить файрвол и автообновление сертификатов. После перезапуска Strongswan на обоих серверах, запустим ping удаленной стороны GRE-туннеля и увидим успешную установку соединения. На VPS (rkn):
И на стороне хоста ipsecgw
Туннель установлен, пинги ходят, в tcpdump видно что между хостами ходит только ESP. Казалось бы можно радоваться. Но нельзя расслабляться не проверив всё до конца. Пробуем перевыпустить сертификат на VPS и…
Шеф, всё сломалось
Начинаем разбираться и натыкаемся на одну неприятную особенность прекрасного во всём остальном Let’s Encrypt — при любом перевыпуске сертификата меняется так же ассоциированный с ним закрытый ключ. Изменился закрытый ключ — изменился и открытый. На первый взгляд ситуация для нас безвыходная: если даже открытый ключ мы можем легко извлечь во время перевыпуска сертификата при помощи хука в certbot и передать его удаленной стороне через SSH, то непонятно как заставить удаленный Strongswan перечитать его. Но помощь пришла откуда не ждали — systemd умеет следить за изменениями файловой системы и запускать ассоциированные с событием службы. Этим мы и воспользуемся.
Создадим на каждом из хостов служебного пользователя keywatcher с максимально урезанными правами, сгенерируем каждому из них SSH-ключи и обменяемся ими между хостами.
На хосте ipsecgw.example.com создадим каталог /opt/ipsec-pubkey в котором разместим 2 скрипта.
На VPS (хосте rkn.example.com) аналогично создаем каталог с тем же именем, в котором тоже создаем аналогичные скрипты, изменяя только название ключа. Код, чтобы не загромождать статью, под
sudo vi /opt/ipsec-pubkey/pubkey-copy.sh
Скрипт pubkey-copy.sh нужен для извлечения открытой части ключа и копирования его удаленному хосту во время выпуска нового сертификата. Для этого в каталоге /etc/letsencrypt/renewal-hooks/deploy на обоих серверах создаем еще один микроскрипт:
Половина проблемы решена, сертификаты перевыпускаются, публичные ключи извлекаются и копируются между серверами и пришло время systemd с его path-юнитами.
На сервере ipsecgw.example.com в каталоге /etc/systemd/system создаем файл keyupdater.path
Аналогично на VPS хосте:
И, напоследок, на каждом сервере создаем ассоциированную с данным юнитом службу, которая будет запускаться при выполнении условия (PathChanged) — изменении файла и его закрытии его после записи. Создаем файлы /etc/systemd/system/keyupdater.service и прописываем:
Не забываем перечитать конфигурации systemd при помощи sudo systemctl daemon-reload и назначить path-юнитам автозапуск через sudo systemctl enable keyupdater.path && sudo systemctl start keyupdater.path.
Как только удаленный хост запишет файл, содержащий публичный ключ, в домашний каталог пользователя keywatcher и файловый дескриптор будет закрыт, systemd автоматически запустит соответствующую службу, которая скопирует ключ в нужное расположение и перезапустит Strongswan. Туннель будет установлен, используя правильный открытый ключ второй стороны.
Можно выдохнуть и наслаждаться результатом.
Вместо заключения
Как мы только что увидели чёрт IPSec не так страшен, как его малюют. Всё, что было описано — полностью рабочая конфигурация, которая используется в настоящее время. Даже без особых знаний можно настроить VPN и надежно защитить свои данные.
Конечно за рамками статьи остались моменты настройки iptables, но и сама статья уже получилась и без того объемная и про iptables написано много.
Есть в статье и моменты, которые можно улучшить, будь-то отказ от перезапусков демона Strongswan, перечитывая его конфиги и сертификаты, но у меня не получилось этого добиться.
Впрочем и рестарты демона оказались не страшны: происходит потеря одного-двух пингов между пирами, мобильные клиенты тоже сами восстанавливают соединение.
Надеюсь коллеги в комментариях подскажут правильное решение.
Анатомия IPsec. Проверяем на прочность легендарный протокол
В современном мире различные VPN-технологии используются повсеместно. Некоторые (например, PPTP) со временем признаются небезопасными и постепенно отмирают, другие (OpenVPN), наоборот, с каждым годом наращивают обороты. Но бессменным лидером и самой узнаваемой технологией для создания и поддержания защищенных частных каналов по-прежнему остается IPsec VPN. Иногда при пентесте можно обнаружить серьезно защищенную сеть с торчащим наружу лишь пятисотым UDP-портом. Все остальное может быть закрыто, пропатчено и надежно фильтроваться.
В такой ситуации может возникнуть мысль, что здесь и делать-то особо нечего. Но это не всегда так. Кроме того, широко распространена мысль, что IPsec даже в дефолтных конфигурациях неприступен и обеспечивает должный уровень безопасности. Именно такую ситуацию сегодня и посмотрим на деле. Но вначале, для того чтобы максимально эффективно бороться c IPsec, нужно разобраться, что он собой представляет и как работает. Этим и займемся!
IPsec изнутри
Перед тем как переходить непосредственно к самому IPsec, неплохо бы вспомнить, какие вообще бывают типы VPN. Классификаций VPN великое множество, но мы не будем глубоко погружаться в сетевые технологии и возьмем самую простую. Поэтому будем делить VPN на два основных типа — site-to-site VPN-подключения (их еще можно назвать постоянные) и remote access VPN (RA, они же временные).
Первый тип служит для постоянной связи различных сетевых островков, например центрального офиса со множеством разбросанных филиалов. Ну а RA VPN представляет собой сценарий, когда клиент подключается на небольшой промежуток времени, получает доступ к определенным сетевым ресурсам и после завершения работы благополучно отключается.
Нас будет интересовать именно второй вариант, так как в случае успешной атаки удается сразу же получить доступ к внутренней сети предприятия, что для пентестера достаточно серьезное достижение. IPsec, в свою очередь, позволяет реализовывать как site-to-site, так и remote access VPN. Что же это за технология и из каких компонентов она состоит?
Стоит отметить, что IPsec — это не один, а целый набор различных протоколов, которые обеспечивают прозрачную и безопасную защиту данных. Специфика IPsec состоит в том, что он реализуется на сетевом уровне, дополняя его таким образом, чтобы для последующих уровней все происходило незаметно. Основная сложность состоит в том, что в процессе установления соединения двум участникам защищенного канала необходимо согласовать довольно большое количество различных параметров. А именно — они должны аутентифицировать друг друга, сгенерировать и обменяться ключами (причем через недоверенную среду), а также договориться, с помощью каких протоколов шифровать данные.
Именно по этой причине IPsec и состоит из стека протоколов, обязанность которых лежит в том, чтобы обеспечить установление защищенного соединения, его работу и управление им. Весь процесс установления соединения включает две фазы: первая фаза применяется для того, чтобы обеспечить безопасный обмен ISAKMP-сообщений уже во второй фазе. ISAKMP (Internet Security Association and Key Management Protocol) — это протокол, который служит для согласования и обновления политик безопасности (SA) между участниками VPN-соединения. В этих политиках как раз и указано, с помощью какого протокола шифровать (AES или 3DES) и с помощью чего аутентифицировать (SHA или MD5).
Две основные фазы IPsec
Итак, мы выяснили, что вначале участникам нужно договориться, с помощью каких механизмов будет создано защищенное соединение, поэтому теперь в дело вступает протокол IKE. IKE (Internet Key Exchange) используется для формирования IPsec SA (Security Association, те самые политики безопасности), проще говоря — согласования работы участников защищенного соединения. Через этот протокол участники договариваются, какой алгоритм шифрования будет применен, по какому алгоритму будет производиться проверка целостности и как аутентифицировать друг друга. Нужно заметить, что на сегодняшний день существует две версии протокола: IKEv1 и IKEv2. Нас будет интересовать только IKEv1: несмотря на то что IETF (The Internet Engineering Task Force) впервые представили его в 1998 году, он по-прежнему еще очень часто используется, особенно для RA VPN (см. рис. 1).
Рис. 1. Cisco ASDM VPN Wizard
Что касается IKEv2, первые его наброски были сделаны в 2005 году, полностью описан он был в RFC 5996 (2010 год), и лишь в конце прошлого года он был объявлен на роль стандарта Интернет (RFC 7296). Более подробно про различия между IKEv1 и IKEv2 можно прочитать во врезке. Разобравшись с IKE, возвращаемся к фазам IPsec. В процессе первой фазы участники аутентифицируют друг друга и договариваются о параметрах установки специального соединения, предназначенного только для обмена информацией о желаемых алгоритмах шифрования и прочих деталях будущего IPsec-туннеля. Параметры этого первого туннеля (который еще называется ISAKMP-туннель) определяются политикой ISAKMP. Первым делом согласуются хеши и алгоритмы шифрования, далее идет обмен ключами Диффи-Хеллмана (DH), и лишь затем происходит выяснение, кто есть кто. То есть в последнюю очередь идет процесс аутентификации, либо по PSK-, либо по RSA-ключу. И если стороны пришли к соглашению, то устанавливается ISAKMP-туннель, по которому уже проходит вторая фаза IKE.
На второй фазе уже доверяющие друг другу участники договариваются о том, как строить основной туннель для передачи непосредственно данных. Они предлагают друг другу варианты, указанные в параметре transform-set, и, если приходят к согласию, поднимают основной туннель. Важно подчеркнуть, что после его установления вспомогательный ISAKMP-туннель никуда не девается — он используется для периодического обновления SA основного туннеля. В итоге IPsec в некоем роде устанавливает не один, а целых два туннеля.
Как обрабатывать данные
Теперь пару слов про transform-set. Нужно ведь как-то шифровать данные, идущие через туннель. Поэтому в типовой конфигурации transform-set представляет собой набор параметров, в которых явно указано, как нужно обрабатывать пакет. Соответственно, существует два варианта такой обработки данных — это протоколы ESP и AH. ESP (Encapsulating Security Payload) занимается непосредственно шифрованием данных, а также может обеспечивать проверку целостности данных. AH (Authentication Header), в свою очередь, отвечает лишь за аутентификацию источника и проверку целостности данных.
Например, команда `crypto ipsec transform-set SET10 esp-aes` укажет роутеру, что transform-set с именем `SET10` должен работать только по протоколу ESP и c шифрованием по алгоритму AES. Забегая вперед, скажу, что здесь и далее мы будем использовать в качестве цели маршрутизаторы и файрволы компании Cisco. Собственно с ESP все более-менее понятно, его дело — шифровать и этим обеспечивать конфиденциальность, но зачем тогда нужен AH? AH обеспечивает аутентификацию данных, то есть подтверждает, что эти данные пришли именно от того, с кем мы установили связь, и не были изменены по дороге. Он обеспечивает то, что еще иногда называется anti-replay защитой. В современных сетях AH практически не используется, везде можно встретить только ESP.
Параметры (они же SA), выбираемые для шифрования информации в IPsec-туннеле, имеют время жизни, по истечении которого должны быть заменены. По умолчанию параметр lifetime IPsec SA составляет 86 400 с, или 24 ч.
В итоге участники получили шифрованный туннель с параметрами, которые их всех устраивают, и направляют туда потоки данных, подлежащие шифрованию. Периодически, в соответствии с lifetime, обновляются ключи шифрования для основного туннеля: участники вновь связываются по ISAKMP-туннелю, проходят вторую фазу и заново устанавливают SA.
Режимы IKEv1
Мы рассмотрели в первом приближении основную механику работы IPsec, но необходимо заострить внимание еще на нескольких вещах. Первая фаза, помимо всего прочего, может работать в двух режимах: main mode или aggressive mode. Первый вариант мы уже рассмотрели выше, но нас интересует как раз aggressive mode. В этом режиме используется три сообщения (вместо шести в main-режиме). При этом тот, кто инициирует соединение, отдает все свои данные разом — что он хочет и что умеет, а также свою часть обмена DH. Затем ответная сторона сразу завершает свою часть генерации DH. В итоге в этом режиме, по сути, всего два этапа. То есть первые два этапа из main mode (согласование хешей и обмен DH) как бы спрессовываются в один. В результате этот режим значительно опаснее по той причине, что в ответ приходит много технической информации в plaintext’е. И самое главное — VPN-шлюз может прислать хеш пароля, который используется для аутентификации на первой фазе (этот пароль еще часто называется pre-shared key или PSK).
Ну а все последующее шифрование происходит без изменений, как обычно. Почему же тогда этот режим по-прежнему используется? Дело в том, что он намного быстрее, примерно в два раза. Отдельный интерес для пентестера представляет тот факт, что aggressive-режим очень часто используется в RA IPsec VPN. Еще одна небольшая особенность RA IPsec VPN при использовании агрессивного режима: когда клиент обращается к серверу, он шлет ему идентификатор (имя группы). Tunnel group name (см. рис. 2) — это имя записи, которая содержит в себе набор политик для данного IPsec-подключения. Это уже одна из фич, специфичных оборудованию Cisco.
Рис. 2. Tunnel group name
Двух фаз оказалось недостаточно
Казалось бы, что получается и так не слишком простая схема работы, но на деле все еще чуть сложнее. Со временем стало ясно, что только одного PSK недостаточно для обеспечения безопасности. Например, в случае компрометации рабочей станции сотрудника атакующий смог бы сразу получить доступ ко всей внутренней сети предприятия. Поэтому была разработана фаза 1.5 прямо между первой и второй классическими фазами. К слову, эта фаза обычно не используется в стандартном site-to-site VPN-соединении, а применяется при организации удаленных VPN-подключений (наш случай). Эта фаза содержит в себе два новых расширения — Extended Authentication (XAUTH) и Mode-Configuration (MODECFG).
XAUTH — это дополнительная аутентификация пользователей в пределах IKE-протокола. Эту аутентификацию еще иногда называют вторым фактором IPsec. Ну а MODECFG служит для передачи дополнительной информации клиенту, это может быть IP-адрес, маска, DNS-сервер и прочее. Видно, что эта фаза просто дополняет ранее рассмотренные, но полезность ее несомненна.
IKEv2 vs IKEv1
Оба протокола работают по UDP-порту с номером 500, но между собой несовместимы, не допускается ситуация, чтобы на одном конце туннеля был IKEv1, а на другом — IKEv2. Вот основные отличия второй версии от первой:
— В IKEv2 больше нет таких понятий, как aggressive- или main-режимы.
— В IKEv2 термин первая фаза заменен на IKE_SA_INIT (обмен двумя сообщениями, обеспечивающий согласование протоколов шифрования/хеширования и генерацию ключей DH), а вторая фаза — на IKE_AUTH (тоже два сообщения, реализующие собственно аутентификацию).
— Mode Config (то, что в IKEv1 называлось фаза 1.5) теперь описан прямо в спецификации протокола и является его неотъемлемой частью.
— В IKEv2 добавился дополнительный механизм защиты от DoS-атак. Суть его в том, что прежде, чем отвечать на каждый запрос в установлении защищенного соединения (IKE_SA_INIT) IKEv2, VPN-шлюз шлет источнику такого запроса некий cookie и ждет ответа. Если источник ответил — все в порядке, можно начинать с ним генерацию DH. Если же источник не отвечает (в случае с DoS-атакой так и происходит, эта техника напоминает TCP SYN flood), то VPN-шлюз просто забывает о нем. Без этого механизма при каждом запросе от кого угодно VPN-шлюз бы пытался сгенерировать DH-ключ (что достаточно ресурсоемкий процесс) и вскоре бы столкнулся с проблемами. В итоге за счет того, что все операции теперь требуют подтверждения от другой стороны соединения, на атакуемом устройстве нельзя создать большое количество полуоткрытых сессий.
Выходим на рубеж
Наконец-то разобравшись с особенностями работы IPsec и его компонентов, можно переходить к главному — к практическим атакам. Топология будет достаточно простой и в то же время приближенной к реальности (см. рис. 3).
Рис. 3. Общая схема сети
Первым делом нужно определить наличие IPsec VPN шлюза. Сделать это можно, проведя сканирование портов, но здесь есть небольшая особенность. ISAKMP использует протокол UDP, порт 500, а между тем дефолтное сканирование с помощью Nmap затрагивает только TCP-порты. И в результате будет сообщение: `All 1000 scanned ports on 37.59.0.253 are filtered`.
Создается впечатление, что все порты фильтруются и как бы открытых портов нет. Но выполнив команду
убеждаемся в том, что это не так и перед нами действительно VPN-устройство.
Атакуем первую фазу
Теперь нас будет интересовать первая фаза, aggressive-режим и аутентификация с использованием pre-shared key (PSK). В этом сценарии, как мы помним, VPN-устройство или отвечающая сторона отправляет хешированный PSK инициатору. Одна из самых известных утилит для тестирования протокола IKE — это ike-scan, она входит в состав дистрибутива Kali Linux. Ike-scan позволяет отправлять IKE сообщения с различными параметрами и, соответственно, декодить и парсить ответные пакеты. Пробуем прощупать целевое устройство:
Рис. 4. Ike-scan aggressive mode
Ключ `-A` указывает на то, что нужно использовать aggressive-режим, а `-M` говорит о том, что результаты следует выводить построчно (multiline), для более удобного чтения. Видно, что никакого результата не было получено. Причина состоит в том, что необходимо указать тот самый идентификатор, имя VPN-группы. Разумеется, утилита ike-scan позволяет задавать этот идентификатор в качестве одного из своих параметров. Но так как пока он нам неизвестен, возьмем произвольное значение, например 0000.
Рис. 5. Ike-scan ID
В этот раз видим, что ответ был получен (см. рис. 5) и нам было предоставлено довольно много полезной информации. Достаточно важная часть полученной информации — это transform-set. В нашем случае там указано, что «Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=PSK».
Все эти параметры можно указывать и для утилиты ike-scan с помощью ключа `—trans`. Например `—trans=5,2,1,2` будет говорить о том, что алгоритм шифрования 3DES, хеширование HMAC-SHA, метод аутентификации PSK и второй тип группы DH (1024-bit MODP). Посмотреть таблицы соответствия значений можно по этому адресу. Добавим еще один ключ (`-P`), для того чтобы вывести непосредственно пейлоад пакета, а точнее хеш PSK.
Рис. 6. Ike-scan payload
Преодолеваем первые сложности
Казалось бы, хеш получен и можно пробовать его брутить, но все не так просто. Когда-то очень давно, в 2005 году, на некоторых железках Сisco была уязвимость: эти устройства отдавали хеш, только если атакующий передавал корректное значение ID. Сейчас, естественно, встретить такое оборудование практически невозможно и хешированное значение присылается всегда, независимо от того, правильное значение ID отправил атакующий или нет. Очевидно, что брутить неправильный хеш бессмысленно. Поэтому первая задача — это определить корректное значение ID, чтобы получить правильный хеш. И в этом нам поможет недавно обнаруженная уязвимость.
Дело в том, что существует небольшая разница между ответами во время начального обмена сообщениями. Если кратко, то при использовании правильного имени группы происходит четыре попытки продолжить установление VPN-соединения плюс два зашифрованных пакета второй фазы. В то время как в случае неправильного ID в ответ прилетает всего лишь два пакета. Как видим, разница достаточно существенная, поэтому компания SpiderLabs (автор не менее интересного инструмента Responder) разработала сначала PoC, а затем и утилиту IKEForce для эксплуатации этой уязвимости.
В чем сила IKE
Установить IKEForce в произвольный каталог можно, выполнив команду
Работает она в двух основных режимах — режиме вычисления `-e` (enumeration) и режиме брутфорса `-b` (bruteforce). До второго мы еще дойдем, когда будем смотреть атаки на второй фактор, а вот первым сейчас и займемся. Перед тем как начать непосредственно процесс определения ID, необходимо установить точное значение transform-set. Мы его уже определили ранее, поэтому будем указывать опцией `-t 5 2 1 2`. В итоге выглядеть процесс нахождения ID будет следующим образом:
Рис. 7. IKEForce enumeration
В результате достаточно быстро удалось получить корректное значение ID (рис. 7). Первый шаг пройден, можно двигаться дальше.
Получаем PSK
Теперь необходимо, используя правильное имя группы, сохранить PSK-хеш в файл, сделать это можно с помощью ike-scan:
И теперь, когда правильное значение ID было подобрано и удалось получить корректный хеш PSK, мы можем наконец-то начать офлайн-брутфорс. Вариантов такого брутфорса достаточно много — это и классическая утилита psk-crack, и John the Ripper (с jumbo-патчем), и даже oclHashcat, который, как известно, позволяет задействовать мощь GPU. Для простоты будем использовать psk-crack, который поддерживает как прямой брутфорс, так и атаку по словарю:
Рис. 8. Psk-crack
Но даже успешно восстановить PSK (см. рис. 8) — это только половина дела. На этом этапе нужно вспомнить про то, что дальше нас ждет XAUTH и второй фактор IPsec VPN.
Расправляемся со вторым фактором IPsec
Итак, напомню, что XAUTH — это дополнительная защита, второй фактор аутентификации, и находится он на фазе 1.5. Вариантов XAUTH может быть несколько — это и проверка по протоколу RADIUS, и одноразовые пароли (OTP), и обычная локальная база пользователей. Мы остановимся на стандартной ситуации, когда для проверки второго фактора используется локальная база пользователей. До недавнего времени не существовало инструмента в публичном доступе для брутфорса XAUTH. Но с появлением IKEForce эта задача получила достойное решение. Запускается брутфорс XAUTH достаточно просто:
Рис. 9. IKEForce XAUTH
При этом указываются все найденные ранее значения: ID (ключ `-i`), восстановленный PSK (ключ `-k`) и предполагаемый логин (ключ `-u`). IKEForce поддерживает как грубый перебор логина, так и перебор по списку логинов, который может быть задан параметром `-U`. На случай возможных блокировок подбора есть опция `-s`, позволяющая снизить скорость брутфорса. К слову, в комплекте с утилитой идут несколько неплохих словарей, особенно полезных для установления значения параметра ID.
Входим во внутреннюю сеть
Теперь, когда у нас есть все данные, остается последний шаг — собственно проникновение в локальную сеть. Для этого нам понадобится какой-нибудь VPN-клиент, которых великое множество. Но в случае Kali можно без проблем воспользоваться уже предустановленным — VPNC. Для того чтобы он заработал, нужно подкорректировать один конфигурационный файл — `/etc/vpnc/vpn.conf`. Если его нет, то нужно создать и заполнить ряд очевидных параметров:
IPSec gateway 37.59.0.253
IPSec ID vpn
IPSec secret cisco123
IKE Authmode psk
Xauth Username admin
Xauth password cisco
Здесь мы видим, что были использованы абсолютно все найденные на предыдущих шагах данные — значение ID, PSK, логин и пароль второго фактора. После чего само подключение происходит одной командой:
Отключение тоже достаточно простое:
Проверить работоспособность подключения можно, используя команду `ifconfig tun0`.
Рис. 10. VPNC
Как построить надежную защиту
Защита от рассмотренных сегодня атак должна быть комплексной: нужно вовремя устанавливать патчи, использовать стойкие pre-shared ключи, которые по возможности вовсе должны быть заменены на цифровые сертификаты. Парольная политика и другие очевидные элементы ИБ также играют свою немаловажную роль в деле обеспечения безопасности. Нельзя не отметить и тот факт, что ситуация постепенно меняется, и со временем останется только IKEv2.
Что в итоге
Мы рассмотрели процесс аудита RA IPsec VPN во всех подробностях. Да, безусловно, задача эта далеко не тривиальна. Нужно проделать немало шагов, и на каждом из них могут поджидать трудности, но зато в случае успеха результат более чем впечатляющий. Получение доступа к внутренним ресурсам сети открывает широчайший простор для дальнейших действий. Поэтому тем, кто ответствен за защиту сетевого периметра, необходимо не рассчитывать на готовые дефолтные шаблоны, а тщательно продумывать каждый слой безопасности. Ну а для тех, кто проводит пентесты, обнаруженный пятисотый порт UDP — это повод провести глубокий анализ защищенности IPsec VPN и, возможно, получить неплохие результаты.
Впервые опубликовано в журнале Хакер #196.
Автор: Александр Дмитренко, PENTESTIT