![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
Про SSTP
Поисследовал немножко вопрос перевода своей 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, в том числе и с использованием аппаратных токенгов все же есть. Правда. исключительно хреново документирована.
no subject
no subject
А толку? Вопрос ведь не в том, что отдается по каналу связи, а в том что хранится на сервере.
no subject
Проблема с SAML решениями общая со всеми Web штуками — воровство session cookie на клиенте.
no subject
Вот чтобы не было воровства аутентификационных токенов на клиенте, надо авторизовываться по ключам, а секретные ключи хранить на аппаратном токене. Тогда чтобы спереть ключ, нужно будет железяку спереть. Физически.
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...
no subject
no subject
На sstp пытались смотреть, но тоже не осилили клиентские сертификаты, на которых у нас построена бОльшая часть доступов.
no subject
Посмотрел я на cloak. Подозрения вызывает то, что он отсутствует в Debian. (впрочем sstpd - тоже). Почитал еще статью на хабре. Из упомянутого там в дистрибутиве присутсвтет v2ray, который на самом деле v2fly. А вот здесь рекомендуют openconnect. Только для того чтобы там работал режим camouflage придется из sid ocserv бэкпортить.
no subject
Openconnect — штука хорошая, есть планы по переезду на него, но это пока только планы, потому не упоминал.
no subject
pppd -- это хорошая идея для использования совместно с чем-то другим. pppd лишь заворачивает траффик в последовательный канал, а дальше этот последовательный канал может быть каким-то образом завёрнут в SSL, где уже будет авторизация на основе сертификатов и т.п. Впрочем вместо pppd кажется подойдёт и vtun.
К сожалению, в linux'овом pppd всё плохо с multilink. Оно толком не работает, виснет, куда-то пропадает траффик. Я не разобрался. Multilink был бы интересен, чтоб обойти такую проблему TCP, что одни пакеты в канале не могут обгонять другие и когда буфер сокета уже заполнен, всё упирается в очередь (даже разные не связанные соединения). Вроде в FreeBSD хороший ppp демон, но он увы не работает в линуксе.
Практически pppd может работать совместно с trojan-gfw например. Впрочем последний детектируется тривиально по размеру пакетов. И в нём течёт память.
no subject
no subject
Вот sstp это и есть "что-то другое" что выполняет заворачиваение ppp в SSL-сокет. И с учетом того что этому протоколу два десятка лет, и он встроен в Windows Remote Access Server, можно считать что там все уязвимости давно повычищали.
Альтернативой sstp является Cisco AnyConnect вернее его свободная реализация OpenConnect. Там правда ppp внутри нет.
no subject
Да, мне v2ray тоже не очень понравился. Единственный аргкумент в его пользу это то, что современные средтсва DPI умеют обнаруживтаь TLS over TLS и считают его достойным блокировке а xray умеет после tls-хэндшейка весь последующий TLS-траффик не шифровать второй раз (что кстати и ресурсы еще экономит).