L2TP & «IPsec with pre shared key» vs MITM
В статье рассмотрены основные vpn протоколы, которые на текущий момент применимы в бизнес процессах, а также углубленно освещен вопрос использования L2TP в связке с IPsec в режиме pre shared key. На практике разобраны подходы к организации виртуальных сетей на оборудовании MikroTik и выполнен практический аудит безопасности передачи данных с позиции анализа третьими лицами исходящего трафика при возможности MITM атаки.
Vpn технологии прочно вошли не только в корпоративную среду, но и в повседневную жизнь многих IT и других специалистов в реализации рабочих и личных проектов. Если перед вторыми вопрос безопасности может вставать исключительно с исследовательским интересом, то для бизнеса важно понимать риски, связанные с эксплуатацией различных информационных процессов в задействованной инфраструктуре, слабые и сильные места, а также экономическое обоснование применяемых решений. Безопасность стоит денег, но не всегда стоит подходить к этому вопросу, как к неприступной крепости, при условии правильной оценки складывающейся ситуации.
Для начала разберем, в каких случаях бизнесу нужен vpn: при подключении удаленных сотрудников к сетевым ресурсам компании (site-to-client vpn) и при объединении территориально разнесенных сетевых элементов (site-to-site vpn). Самих протоколов vpn сейчас много: GRE, PPTP, SSTP, OVPN, L2TP, Wireguard и т.д.
Здесь важно не путать протоколы с сервисами vpn, которых еще больше: ExpressVPN, CyberGhost, NordVPN и т.д. Вторые по сути являются провайдерами услуг, обеспечивая доступ клиентов к собственным ресурсам с целью обхода блокировок со стороны ISP, а также анонимности серфинга в интернете. Про них сейчас речь не идет.
С вариацией протоколов определились, какой же выбрать?
Во-первых, в зависимости от того, что строим site-to-client или site-to-site, потому что GRE для первого случая не подойдет.
Во-вторых, Wireguard хоть молодой, простой и очень перспективный, но на офисном маршрутизаторе Cisco или MikroTik его не поднять, вендоры даже не планируют внедрять. PPTP очень легок в настройке, однако будет либо не шифрованным, либо шифрованным протоколом MPPE, который не имеет аппаратной разгрузки, в следствие чего, многопользовательскую сеть замедлит в работе. SSTP отличный протокол, работает по TLS в UDP на 443 порту, пролезет через любой Firewall, а может даже и IDS. У некоторых вендоров, например, MikroTik, может работать по pre shared key вместо сертификата, запускается на Windows клиентах из коробки.
Из минусов: определенные танцы с бубном при настройке Linux клиентов (протокол все-таки от Microsoft) и отсутствие поддержки со стороны вендоров в аппаратной разгрузке. OpenVPN всем хорош, особенно высокой гибкостью. Можно туннелировать на L2, можно на L3, всего не перечислить. Не даром он open soft. Роутер MikroTik скоро научится работать с ним по UDP (ожидается в следующем поколении RouterOS), так как смысла в TCP нет, ведь соединение все равно проверяется во вложенном туннеле. Однако, скорее всего ваша офисная Cisco не умеет с ним работать, поэтому vpn сервер из нее не организовать.
Фактически, стандартом де-факто в корпоративной среде является протокол L2TP. Он работает на UDP, порт по умолчанию 1701. С шифрованием все хорошо, особенно наличие возможности аппаратной разгрузки IPsec. Есть вероятность, что ваш корпоративный MikroTik (несмотря на то, что он софтовый маршрутизатор) умеет шифровать IPsec на железе (смотри таблицу «Hardware acceleration» на сайте производителя). У Cisco в этом вопросе дела обстоят еще лучше. Даже если ваш офисный роутер не умеет шифровать железом, никто кроме вас это знать не должен не будет.
Итак, подведем промежуточный итог: vpn технологии бизнесу нужны, использовать лучше всего L2TP. Закончив с затянувшейся вводной частью, перейдем непосредственно к теме статьи. Рассмотрим на примере оборудования MikroTik безопасность передачи данных в туннеле при возможности MITM атаки со стороны третьих лиц. Этот вопрос возникает в следствие того, что почти всегда в корпоративной среде используют L2TP в связке с IPsec в туннельном режиме и общим ключем для всей сети, вместо создания PKI и задействования сертификатов. Это удобно, сеть быстро разворачивается и легко обслуживается. Безопасно ли это в условиях компрометации pre shared key? Разберем на практике.
— Начнем с того, что L2TP может быть не шифрованным:
/ppp profile name=test use-encryption=no
— с интегрированным в протокол шифрованием MPPE:
/ppp profile name=test use-encryption=yes (или require, при этом IPsec отключен)
— с качественным внешним шифрованием от IPsec, вроде AES:
/ppp profile name=test use-encryption=yes (или require, при этом IPsec включен)
Настройка L2TP сервера осуществляется достаточно просто, активируем его и указываем тип аутентификации:
/interface l2tp-server server set authentication=mschap2 default-profile=test enabled=yes
Здесь же появляется возможность сразу активировать IPsec и настроить pre shared key. Если это сделать, то общий ключ будет закреплен за всей vpn сетью и передан всем ее участникам в качестве настроечной информации. Один и тот же на всех. На самом деле, если активировать IPsec таким образом, то RouterOS автоматически создает необходимые настройки в соответствующем разделе /ip ipsec сразу после установления L2TP соединения.
Конкретно речь идет:
- IPsec Policy с указанными протоколом UDP и портом подключения 1701;
- IPsec Peer c IP адресами сервера и клиента;
- IPsec Identity с указанным ранее pre shared key.
Очень удобно. Особенно, когда IP адреса динамические и вообще натированные. Клиентам не нужно выполнять лишние процедуры по отслеживанию их текущих значений. В RouterOS в разделе L2TP есть дополнительная настройка, определяющая общий секрет при конфигурировании в сетях Virtual Private DialUp Network протяженных соединений точка-точка между удаленным сервером PPPOE и L2TP сетью, но это к теме статьи не относиться, поэтому просто ее упомянем всуе:
/ppp l2tp-secret add address=0.0.0.0/0 secret=Допустим, мы не хотим простого счастья и дополнительно желаем, чтобы у каждого клиента был индивидуальный сертификат вместо общего ключа (возможно, для этого в компании уже все готово). Звучит очень круто и безопасно. Нет технически не преодолимых проблем, кроме танцев с бубнами: создаем все вышеперечисленное в ручном режиме, не забываем про корректно заданные IP адреса, как со стороны сервера, так и со стороны клиентов.
/ip ipsec peer add address=IP local-address=IP name=peer1
/ip ipsec identity add peer=peer1 auth-method=digital-signature certificate=u01.crt_0
/ip ipsec policy add dst-address=IP dst-port=1701 peer=peer1 protocol=udp src-address=IP src-port=1701
Здесь нас поджидает кропотливая работа, ведь, скорее всего, адреса у клиентов меняются (и достаточно часто), кроме этого клиенты сидят за провайдорским NAT. Все это можно накрутить кастомными скриптами на RouterOS, и все будет отлично работать. Нужно ли это? Cмоделируем ситуацию, когда общий для всех pre shared key стал известен злоумышленнику, который целенаправленно хочет нам навредить. Или клиент vpn нам больше не клиент. Сразу баним его учетную запись, и теперь аутентификацию mschap2 (или какая у вас там выбрана) он не пройдет и доступ не получит:
/ppp secret disable bad_userЕсли каким-то чудом у него есть возможность MITM, то есть пропускать трафик через себя, то толку в этом ровно никакого нет. Весь трафик зашифрован. Выдать себя за vpn сервер другим участникам корпоративной сети тоже не удастся. В подобном нереальном сценарии аутентификацию mschap2 клиенты не пройдут, ведь их секрет известен только им и вам, разумеется:
/ppp secret add name=good_user password=12345 service=l2tp
Шифрованный трафик L2TP туннеляИсследовательский интерес нас ведет дальше. Может все-таки что-то можно сделать с трафиком? И в результате извлечь передаваемую информацию? Попробуем дешифровать трафик в лабораторных условиях. MikroTik позволяет нам выполнить debug соединения и увидеть подробную информацию об установленной IPsec сессии:
Как видно, сессия установилась на 30 минут, имеются разные ключи аутентификации и шифрования. Применим их в Wireshark, после приведения шестнадцатеричных значений к корректному формату: SPI 0×0ada181b, вместо MikroTik-овского 0xADA181B, ключи начинаются со значения 0x. Если все сделано правильно, тогда трафик откроется.
Подведем результаты
Насколько безопасно использовать L2TP c общим секретом? Абсолютно безоапасно. По сути IPsec с помощью pre shared key выполняет функцию аутентификации, но в нашем случае процедура аутентификации выполняется ранее при установлении L2TP соединения. Нет практической необходимости выполнять аутентификацию повторно. По сути MikroTik, введя возможность настройки IPsec в разделе создания L2TP сервера, автоматизирует рутинные задачи по настройке шифрованного туннеля в ручном режиме (история про танцы с бубном). Это еще один плюс в сторону использования не дорогостоящего, но качественного оборудования MikroTik. Конечно, в ручном режиме гораздо больше вариаций на тему шифрования, но по умолчанию задаются, по авторскому мнению, идеальные значения: aes256 и sha1.
Как рекомендации для бизнеса, смело можно использовать L2TP с IPsec pre shared key. При планировании политик информационной безопасности, нет необходимости в задании сложных значений для pre shared key. Важно выставить не угадываемые и не словарно подбираемые значения для аутентификации L2TP (/ppp secret). Удобно, безопасно и качественно, админ доволен, клиенты не замучены.
