Comments 26
1)А какой тогда вообще смысл в общем секрете если его разглашение ни на что не влияет?
2)Может подскажете как в l2tp на микротике dns суффикс засунуть? В dhcp такая опция есть, но в l2tp же свой dhcp и вот его-то вроде никак не настроить.
3)router os 7 вроде же хотели wireguard сделать?
4)openvpn L2 на android не работает.
2)Может подскажете как в l2tp на микротике dns суффикс засунуть? В dhcp такая опция есть, но в l2tp же свой dhcp и вот его-то вроде никак не настроить.
3)router os 7 вроде же хотели wireguard сделать?
4)openvpn L2 на android не работает.
1) Мое видение, это вариант реализации от вендора.
2) Поясните подробнее, пожалуйста.
3) В бета версии пока пусто.
4) L2 засовывать в VPN канал? Вам точно это нужно?
2) Поясните подробнее, пожалуйста.
3) В бета версии пока пусто.
4) L2 засовывать в VPN канал? Вам точно это нужно?
«Насколько безопасно использовать L2TP c общим секретом? Абсолютно безоапасно. По сути IPsec с помощью pre shared key выполняет функцию аутентификации, но в нашем случае процедура аутентификации выполняется ранее при установлении L2TP соединения. Нет практической необходимости выполнять аутентификацию повторно.»
Простите, у вас похоже какое-то странное представление о последовательности установления L2TP/IPSec. СНАЧАЛА устанавливается IPSec SA а уже поверх этого SA открывается сессия L2TP. Таким образом заявление о том что «процедура аутентификации выполняется ранее при установлении L2TP соединения», мягко говоря, неправда
Ну и «Абсолютно безопасно», это конечно шедевр…
Простите, у вас похоже какое-то странное представление о последовательности установления L2TP/IPSec. СНАЧАЛА устанавливается IPSec SA а уже поверх этого SA открывается сессия L2TP. Таким образом заявление о том что «процедура аутентификации выполняется ранее при установлении L2TP соединения», мягко говоря, неправда
Ну и «Абсолютно безопасно», это конечно шедевр…
Давайте вместе обсудим теоретические и практические риски ИБ. В чем вы их ведите? (про аутентификацию поправил, спасибо)
Риски тут следующие.
Во-первых, утечка разделяемого ключа(preshared key) возможной атаку MITM(«человек посредине») на туннель IPSec. Поскольку процедура согласования ассоциации безопасности (SA) в IPSec использует протокол Диффи-Хелмана, не имеющий защиты от MITM, то для безопасности IPSec совершенно необходима аутентификация противоположной стороны соединения. В варианте с разделяемым ключом она реализуется с помощью этого самого ключа: если противоположная сторона им владеет, то она считается принадлежащей группе допустимых партнеров. Так что если разделяемый ключ окажется в руках злоумышленника, тот может включить в эту группу свое устройство, а если злоумышленник ещё и имеет возможность перенаправить на него трафик, то он может организовать незашифрованный участок между двумя тоннелями и собирать на нем трафик. У CISCO есть хорошая картинка на эту тему.
Далее, поскольку трафик по самому себе туннелю L2TP передается в открытом виде без шифрования, злоумышленник получает полную возможность его прослушивать.
В том числе — и трафик аутентификации по MSCHAP v2.
Что касается MSCHAP v2, то этот протокол относится к недостаточно защищенным для нашего времени. Во-первых, поскольку ауттентифкация идет чисто по паролю, то для него возможны атаки с перебором пароля по словарю, а в-вторых, он весьма ограниченно стоек к атке перебором: вычислительная сложность перебора AFAIK соответсвует DES(2^56 вариантов). В 2012 году была работа по демонстрации взлома перебором, но тогда это было недешево: потребовалось специализированное оборудование на базе FPGA. Что для этого требуется сейчас (например, насколько сложно под это дело приспособить оборудование для майнинга криптовалюты) — я не в курсе, но подозреваю, что атака эта стала существенно дешевле.
Вопрос однако в том, насколько эти риски существенны. Дело в том, что атаки хотя и возможны, но, к примеру, скрипт-кидди их не потянут. Так что вопрос тут в цене информации. Финансовую информацию таким образом защищать, наверное, нельзя. А вот подключения сотрудников небольшой фирмы (обычного потребителя MicroTik) — не исключено, что можно.
Ну и ещё: защиту аутентификации по MSCHAP v2 можно усилить, если пустить ее по каналу, защищенному TLS (метод аутентификации PEAP-MSCHAPv2). Если в сети есть Windows Server, то на нем можно поднять сервер RADIUS(NPS), который это заведомо поддерживает, но поддерживает ли это MicroTik в других вариантах — не в курсе.
Во-первых, утечка разделяемого ключа(preshared key) возможной атаку MITM(«человек посредине») на туннель IPSec. Поскольку процедура согласования ассоциации безопасности (SA) в IPSec использует протокол Диффи-Хелмана, не имеющий защиты от MITM, то для безопасности IPSec совершенно необходима аутентификация противоположной стороны соединения. В варианте с разделяемым ключом она реализуется с помощью этого самого ключа: если противоположная сторона им владеет, то она считается принадлежащей группе допустимых партнеров. Так что если разделяемый ключ окажется в руках злоумышленника, тот может включить в эту группу свое устройство, а если злоумышленник ещё и имеет возможность перенаправить на него трафик, то он может организовать незашифрованный участок между двумя тоннелями и собирать на нем трафик. У CISCO есть хорошая картинка на эту тему.
Далее, поскольку трафик по самому себе туннелю L2TP передается в открытом виде без шифрования, злоумышленник получает полную возможность его прослушивать.
В том числе — и трафик аутентификации по MSCHAP v2.
Что касается MSCHAP v2, то этот протокол относится к недостаточно защищенным для нашего времени. Во-первых, поскольку ауттентифкация идет чисто по паролю, то для него возможны атаки с перебором пароля по словарю, а в-вторых, он весьма ограниченно стоек к атке перебором: вычислительная сложность перебора AFAIK соответсвует DES(2^56 вариантов). В 2012 году была работа по демонстрации взлома перебором, но тогда это было недешево: потребовалось специализированное оборудование на базе FPGA. Что для этого требуется сейчас (например, насколько сложно под это дело приспособить оборудование для майнинга криптовалюты) — я не в курсе, но подозреваю, что атака эта стала существенно дешевле.
Вопрос однако в том, насколько эти риски существенны. Дело в том, что атаки хотя и возможны, но, к примеру, скрипт-кидди их не потянут. Так что вопрос тут в цене информации. Финансовую информацию таким образом защищать, наверное, нельзя. А вот подключения сотрудников небольшой фирмы (обычного потребителя MicroTik) — не исключено, что можно.
Ну и ещё: защиту аутентификации по MSCHAP v2 можно усилить, если пустить ее по каналу, защищенному TLS (метод аутентификации PEAP-MSCHAPv2). Если в сети есть Windows Server, то на нем можно поднять сервер RADIUS(NPS), который это заведомо поддерживает, но поддерживает ли это MicroTik в других вариантах — не в курсе.
2)/ip dhcp-server option
add code=15 name=«dns suffix local» value="'local'"
аналогичную конструкцию запихнуть в dhcp для l2tp клиентов.
3)сам не пробовал, но тут forum.mikrotik.com/viewtopic.php?f=1&t=152003#p812227 пишут что добавили почти год как.
4)ну это точно не является необходимым. Но когда-то, когда я делал своё первый VPN чисто для себя, я решил что L2 будет полезным.
а)Можно играть в старые игры по сети, которые не поддерживают TCP.
б)Не знаю насколько проблема актуальна, но 1 раз я столкнулся с проблемой, что программа считала локалкой только одну подсеть.
Но от L2 схемы пришлось отказаться т.к. не поддерживалась андроидом.
add code=15 name=«dns suffix local» value="'local'"
аналогичную конструкцию запихнуть в dhcp для l2tp клиентов.
3)сам не пробовал, но тут forum.mikrotik.com/viewtopic.php?f=1&t=152003#p812227 пишут что добавили почти год как.
4)ну это точно не является необходимым. Но когда-то, когда я делал своё первый VPN чисто для себя, я решил что L2 будет полезным.
а)Можно играть в старые игры по сети, которые не поддерживают TCP.
б)Не знаю насколько проблема актуальна, но 1 раз я столкнулся с проблемой, что программа считала локалкой только одну подсеть.
Но от L2 схемы пришлось отказаться т.к. не поддерживалась андроидом.
2) не пробовал, надо тыкать, или писать вендору, что лучше;
3) интересно, сегодня опробую, отпишусь, не замечал такого в /ppp ;
4) если вы понимаете что для чего это нужно, дело меняет сторону.
2)а как это можно не попробовать? Вы же не пишете FQDN каждый раз? Или у вас по какой-то другой причине dns суффикс подставляется? На форумах вроде пишут что решения со стороны микротика нет… и меня это удивляет, ладно я с маленькой домашней сеткой, а как в энтерпрайзе это работает? не вводят же FQDN каждый раз.
2) надо стучаться к вендору и следить за новостями обновлений;
3) подтверждаю, в бета версии RouterOS 7 уже все есть (/interface wireguard).
3) подтверждаю, в бета версии RouterOS 7 уже все есть (/interface wireguard).
Скажите, зачем вы тут ЭТО пишите? Вы хорошо понимаете что написанное пером, особенно на хабре, не вырубишь и топором? И что прочитают это не только свежевыученые на курсах сетидевопскодингзанеделю вайтишники, перед настройкой микротика в сети пельменных, а еще такие же из какого-нибудь банка? И прочитают они ТОЛЬКО так называемые «рекомендации». Для кого вообще эта статья, зачем в ней сначала объясняют что такое впн (видимо для тех кто не знает), а в конце, этим же людям (sic!) «рекомендуют» раздать всем одинаковый ключ. Они же за чистую воду все примут!
Делать так как написано нельзя, потому что нельзя концептуально, с точки зрения концепции инфобеза. Это — халтура. Учить такому других нельзя тем более. Если Вы не можете придумать систему дистрибуции ключей клиентам, это абсолютно не значит что надо делать ТАК, подсказка, проблема не относится к числу нерешаемых никак
ЗЫ. Во всех мне известных рекомендациях сказано что айписек юзать надо с аутентификацией. А аутентификация ОТЛИЧАЕТСЯ от авторизации, это разные вещи.
Делать так как написано нельзя, потому что нельзя концептуально, с точки зрения концепции инфобеза. Это — халтура. Учить такому других нельзя тем более. Если Вы не можете придумать систему дистрибуции ключей клиентам, это абсолютно не значит что надо делать ТАК, подсказка, проблема не относится к числу нерешаемых никак
ЗЫ. Во всех мне известных рекомендациях сказано что айписек юзать надо с аутентификацией. А аутентификация ОТЛИЧАЕТСЯ от авторизации, это разные вещи.
Проведенный на практике анализ показывает, что pre shared key от MikroTik — это удобно и безопасно. Ваш концептуальный подход, конечно, более правильный, так как многогранен. Следовать рекомендациям и т.д. очень круто, но какой в этом смысл в соотношении с расходами, если трафик реально все равно не достать.
КАКИМИ расходами? Вашими расходами на внедрение дистрибуции ключей? Это Ваша проблема, а не Вашего клиента, может ему нужно найти другого исполнителя, который не ХАЛТУРИТ? Мое мнение делать нужно или правильно или никак не делать. Тем более обычно сделать правильно, например в этом случае, несложно.
Повторюсь, моя претензия не столько в том что на практике так делать нельзя, откуда я знаю, вдруг у вас на практике еще и пароли везде дефолтные и одинаковые, так же удобнее. А в том что вы учите как неправильно делать других людей, которые просто НЕ ЗНАЮТ как правильно.
И что статья не называется «как на скорую руку халтурно поднять впн для сети чебуречных кофеен», а называется она по другому, и еще «рекомендации» с умным видом дает.
Это пока в микротике очередная уязвимость для скрипткиддисов не появилась, юзая которую они на практике залезут везде и вся.
Повторюсь, моя претензия не столько в том что на практике так делать нельзя, откуда я знаю, вдруг у вас на практике еще и пароли везде дефолтные и одинаковые, так же удобнее. А в том что вы учите как неправильно делать других людей, которые просто НЕ ЗНАЮТ как правильно.
И что статья не называется «как на скорую руку халтурно поднять впн для сети чебуречных кофеен», а называется она по другому, и еще «рекомендации» с умным видом дает.
что pre shared key от MikroTik — это удобно и безопасно.
Это пока в микротике очередная уязвимость для скрипткиддисов не появилась, юзая которую они на практике залезут везде и вся.
Вы можете на практике скомпрометировать vpn l2tp сеть с утерянным pre shared key? Мои рекомендации обоснованы на том, что в исследовании этого не удалось сделать. А подвергая сомнению Ваши правильные общепринятые рекомендации можно получить новые знания, как в положительную, так и отрицательную сторону.
Добавлю в копилку критических комментариев, что отношение автора к PKI как к «танцам с бубном» глубоко ошибочно, а распространение такого мнения — просто преступно. Ничего сложного в PKI нету, особенно для VPN. В сети полно описаний создания простейшего СА для частных нужд.
И кстати, sha1 не рекомендуется к использованию с 2011-го года.
И кстати, sha1 не рекомендуется к использованию с 2011-го года.
PKI это классно, когда работа по его поддержанию поставлена на уровне. Если в организации пока ничего для этого нет, развертывание инфраструктуры, и самое главное ее обеспечение может встать в отдельный вопрос, требующий сил и времени, а значит скорее всего и денег. Рисков в использовании sha1 в VPN не вижу никаких, даже в 2021 году.
Это если у вас PKI для сайта, там надо чего-то ставить, обновлять сертификаты своевременно (и часто) правильными скриптами и т.д. Для VPN достаточно иметь корневой вечный самоподписанный сертификат (две команды openssl), файл с отозванными сертификатами и клиентские сертификаты (ещё по три команды openssl). Последние тоже могут быть долгоживущими. Такое даже на мобиле можно сделать.
Безотносительно вопроса безопасности скажу, что в микротиках без аппаратного шифрования использование sha256 вместо sha1 весьма заметно просаживает скорость туннеля (и так-то весьма не великую на девайсах без аппаратного шифрования).
Если каким-то чудом у него есть возможность MITM, то есть пропускать трафик через себя, то толку в этом ровно никакого нет. Весь трафик зашифрован.
Сожалею, что я пропустил это при первом чтении. Потому что атака MITM на IPSec при знании разделяемого ключа, используемого при аутентификации конечных точек тоннеля IPSec, будет выглядеть совсем по-другому — не так, как вы написали.
Если у злоумышленника, знающего разделяемый ключ, есть возможность пропустить через себя весь трафик, начиная с первой фазы IPSec, то он может вмешаться в процесс установления тоннеля IPSec и установить вместо одного тоннеля между клиентом и сервером два тоннеля IPSec: один — между клиентом и своим устройством, другой — между своим устройством и сервером VPN. Я уже приводил ссылку на статью в блоге Cisco, где это проиллюстрировано на примере, когда злоумшленник использует для разных тоннелей разные устройства, но, в принципе, устройство у злоумышленника для конечных точек обоих тоннелей может быть одно и то же. Трафик между конечными точками тоннелей на стороне злоумышленника ничем не зашифрован, и злоумышленник может его свободно, как минимум, читать. В случае L2TP, в котором трафик по его тоннелю передается без шифрования (т.к. он полагается на внешнее шифрование с помощью IPSec) это означает, что злоумышленнику будет доступна вся передаваемая по тоннелю информация.
Статья содержательная, но возникает вопрос, почему не рассмотрен Ipsec ikev2, если ipsec может работать без l2tp, зачем вообще использовать l2tp? Сразу скажу я очень не люблю как микротик так и l2tp. И именно эта нелюбовь привела к тому, что был настроен ipsec ikev2 сервер, с авторизацией по виндовому сертификату который компьютер получает политикой. При этом все прекрасно, а главное нативно работает как с андройдом так и с айфоном. Линукс и МакОС клиенты так же без проблем подключаются, штатными средствами.
IPsec Ikev2 бесспорно расширит статью. Спасибо за представленную практику.
Можно вас попросить предоставить ссылочки\пруфы откуда у вас эта информация?!
SSTP отличный протокол, работает по TLS в UDP на 443 порту
Роутер MikroTik скоро научится работать с ним по UDP (ожидается в следующем поколении RouterOS)
Открываю спеку по протоколу и вижу в тексте только TCP
Sign up to leave a comment.
L2TP & «IPsec with pre shared key» vs MITM