Про SSTP

[vitus_wagner]

Поисследовал немножко вопрос перевода своей VPN с openvpn на sstp. sstp это фактически ppp over tls. То есть отличить это от веб-траффика существенно менее реально. Правда, наиболее распространенной реализацией sstp-сервера пол linux является softether на который у меня аллергия. Он какой-то цисковский по всей идеологии. а не юниксовый.

Правда, существует еще sstpd. Но он вообще на питоне написан. Зато, правда. заточен на работу за полноценным веб-сервером в качестве frontend-proxy.

Кроме этого вопроса с реализациями у SSTP есть проблема с аутентификацией Почему-то не поддерживается в sstpc аутентификация по клиентским сертификатам. Хотя вроде у микрософта в RAS она была. А тут вся аутентификация спихнута на pppd. А в пароли я как-то не верю в наше время. Даже в CHAP.

Upd Оказывается, в linux-овом pppd версии 2.4.9 и выше поддержка EAP-TLS, в том числе и с использованием аппаратных токенгов все же есть. Правда. исключительно хреново документирована.

Comments

[borisk]

Fortinet сделали работу с SAML в этом протоколе. Так что можно отдавать вместо пароля session cookie

[vitus_wagner]

А толку? Вопрос ведь не в том, что отдается по каналу связи, а в том что хранится на сервере.

[borisk]

Когда на шлюзе VPN стоит только SAML SP, «на сервере» пользовательской информации нет, она вся на SAML IdP.

Проблема с SAML решениями общая со всеми Web штуками — воровство session cookie на клиенте.

[vitus_wagner]

Вот чтобы не было воровства аутентификационных токенов на клиенте, надо авторизовываться по ключам, а секретные ключи хранить на аппаратном токене. Тогда чтобы спереть ключ, нужно будет железяку спереть. Физически.

openvpn так может, ssh твк может, микрософтовская реализация SSTP тоже может. А свободные даже не пытаются.

Ну и с session cookiie тоже есть определенные проблемы. Для VPN понятие session как-то не определено. Да и http у нас session less. Поэтому устаревание session cookie это примерно такой же security theater как насильственная смена пароля раз в две недели.

Что касвется разнесения хранилизща авторизационной информации и шлюда VPN по разным устройством, то это да, у данной защитной меры есть своей use case. Но у меня-то не коропоративная сеть. Стоит одна виртуалка в провайдерском датацентре, а все остальные - ее клиенты. Поэтому разнесение авторизационной БД и VPN-сервера по разным процессам в этой виртуалке вряд ли поможет. Хотя ... если засунуть vpn-сервер в chroot, и отобрать у него все привилелгии кроме CAP_NET_ADMIN и CAP_NET_RAW...

[borisk]

Можно и так.

[stanislavvv]

У нас в качестве аварийного входа сделан cloak за одним из вебсерверов с более-менее приличным путём. В нём включили проброс для обоих вариантов openvpn (upd и tcp) и для некоторых любителей — wireguard. С точки зрения openvpn, требуется цепляться не к целевому серверу, а к 127.0.0.1:1984, в остальном всё работает как работало, включая немодифицированный сервер на удалённой стороне.
На sstp пытались смотреть, но тоже не осилили клиентские сертификаты, на которых у нас построена бОльшая часть доступов.

[vitus_wagner]

Посмотрел я на cloak. Подозрения вызывает то, что он отсутствует в Debian. (впрочем sstpd - тоже). Почитал еще статью на хабре. Из упомянутого там в дистрибутиве присутсвтет v2ray, который на самом деле v2fly. А вот здесь рекомендуют openconnect. Только для того чтобы там работал режим camouflage придется из sid ocserv бэкпортить.

[stanislavvv]

Собственно, cloak выбирался в спешке и в том числе с целью минимизации вмешательства в инфраструктуру из того, что умело и udp тоже. Просто проверили — работает. В моменты "учений" используется, в основное время — лучше без него, так как +50мс телефонию не радует.
Openconnect — штука хорошая, есть планы по переезду на него, но это пока только планы, потому не упоминал.

[0xfeedca75]

Проблема современного VPN в том, что он должен быть малообнаружимым. Все типовые протоколы заранее известны и детектируются (и если не блокируются, завтра будут).

pppd -- это хорошая идея для использования совместно с чем-то другим. pppd лишь заворачивает траффик в последовательный канал, а дальше этот последовательный канал может быть каким-то образом завёрнут в SSL, где уже будет авторизация на основе сертификатов и т.п. Впрочем вместо pppd кажется подойдёт и vtun.

К сожалению, в linux'овом pppd всё плохо с multilink. Оно толком не работает, виснет, куда-то пропадает траффик. Я не разобрался. Multilink был бы интересен, чтоб обойти такую проблему TCP, что одни пакеты в канале не могут обгонять другие и когда буфер сокета уже заполнен, всё упирается в очередь (даже разные не связанные соединения). Вроде в FreeBSD хороший ppp демон, но он увы не работает в линуксе.

Практически pppd может работать совместно с trojan-gfw например. Впрочем последний детектируется тривиально по размеру пакетов. И в нём течёт память.

[0xfeedca75]

Штуки вроде v2ray и т.п. с большим объёмом кода и дичайшими зависимостями (и блобами) пугают. Код не обозрим, делается это всё непонятно кем, и недавние истории с xz намекают, что лучше такого сторониться. Тем более немного разбираясь в вопросе начинаешь понимать, что вот такое нагромождение вовсе и не нужно. Потому, что примеры vtun или trojan (C++-версии) показывают, что вагон кода не нужен. Более того, часто может быть достаточно вовсе socat'а. И то же самое касается клиентов для мобильника. Нормальных, кажется, нет вообще. А там казалось бы задачка: простейший UI на Java, установить SSL-соединение (тоже Java вполне достаточна, зачем длинная цепочка зависимостей не понятно), траффик вынуть из SSL-сокета и переложить в tun/tap. Десятки библиотек нативного кода явно тут не нужны.

[vitus_wagner]

Вот sstp это и есть "что-то другое" что выполняет заворачиваение ppp в SSL-сокет. И с учетом того что этому протоколу два десятка лет, и он встроен в Windows Remote Access Server, можно считать что там все уязвимости давно повычищали.

Альтернативой sstp является Cisco AnyConnect вернее его свободная реализация OpenConnect. Там правда ppp внутри нет.

[vitus_wagner]

Да, мне v2ray тоже не очень понравился. Единственный аргкумент в его пользу это то, что современные средтсва DPI умеют обнаруживтаь TLS over TLS и считают его достойным блокировке а xray умеет после tls-хэндшейка весь последующий TLS-траффик не шифровать второй раз (что кстати и ресурсы еще экономит).