Обновлен код:
– Добавлена отправка кодов в Synology Chat и через Telegram Bot
– Возможность отправки различным пользователям по различным каналам
– Упрощен код скрипта для MikroTik
Я вас правильно понял. На маке тоже можно не ставить галочку "отправлять весь трафик через vpn".
Но речь у вас изначально была про невозможность на смартфонах пустить трафик не over vpn, вот я говорю, что проблема локальная для l2tp и его реализации в смартфонах. И проблема тут не в микротах.
Это не камень в огород МТ, а камень в протокол. Вы же не говорите, что на другом оборудовании l2tp можно сделать так, чтобы работало.
Тут «от каждого по желаниям, каждому по потребностям». Лично для меня отсутствие OVPN UDP не является причиной, чтобы отказываться от столь мощного оборудования. Это из разряда извечных споров типа «Android/iOS», «Windows/MacOS», «Huyndai/VW» etc…
Не совсем понял как это относится к теме двухфакторной авторизации, но да, на смартфоне не получится и не только l2tp, но и все остальные, а на MacOS не получится PPTP/SSTP.
Но это решение для рабочего процесса:
– у меня оно используется для авторизации туннелей сервер-микротик и между микротиками, а дальше поднимаю адресацию по OSPF.
– достаточно хорошо будет для авторизации сотрудников работающих на удаленке с компьютера. Я полагаю с телефона никто не работает.
– При соединении офисов в единую сеть данное решение также позволит получать информацию о «падении/подъеме» туннеля. Но это больше вторично, но тоже полезно
И, что не маловажно, если вы/компания строите защищенную сеть и заморочились с 2FA, то шлюз у вас должен быть один, в противном случае в вашу сеть запросто можно зайти, что называется «со двора» – с того устройства у которого основной шлюз не через vpn
TOTP хорошая вещь, но конкретно к данному решению оно увы совсем не подходит.
SMS взломать не получится, т.к отправленный код действует ровно столько сколько действует сессия установленная в idle-timeout. Далее код теряет свою актуальность.
Поэтому если нужна очень высокая защищенность, для критических узлов можно установить timeout vpn-соединения равным 60s.
Заказать дубликат симки даже за час не реально, учитывая то, что еще нужно знать на какой номер отправлялось сообщение и как-то решить вопрос с предоставляемыми документами для заказа дубликата.
Второй момент – для компаний которые используют для защищенного общения внутренние чаты, например тот же Synology Chat, скрипт может отправлять код авторизации через его API и в этом случае система авторизации становится изолированной от внешней среды.
Вот про это я и писал, что у пользователя должен быть токен или приложение, а также на сервере должна быть форма в которую будет выводиться этот код. В данном случае код не нужно передавать пользователю, но наоборот сервер его должен получить от пользователя. Экономия на смс, но неудобство для авторизации. На мой взгляд гораздо проще перейти по ссылке из SMS/email и пр.
Решение задачи с ТОТР усложняется, когда один пользователь может авторизовать несколько туннелей на разных роутерах (возможность заложена в скрипте).
Ну это то, что я и представлял. Но для генерации у клиента должно быть приложение или токен, правильно? Ну и самое главное на сервере еще должна быть страница куда этот пароль вводить.
Ну или приложение, которое генерирует код и отправляет его на сервер «невидимо».
А что вы подразумеваете под – «В случае TOTP пользователю ничего отсылать не нужно, у него код уже есть».
TOTP в моем понимании – метод шифрования пароля со сроком действия. Сгенерировать его можно на сервере, в клиентском приложении или на токене (например), куда изначально уже внесен ключ-секрет. Если у клиента нет приложения или токена и пароль генерировался на сервере, то пароль ему в любом случае нужно передать.
Если написать приложение, то это все меняет, но я увы не пишу их.
Буду рад любым разъяснениям. Может это то, что индустрия ждет и я это реализую на благо сообщества :)
Спасибо за обратную связь.
Я обновил код добавив возможность отправки SMS через платный шлюз, на примере smsc.ru (цена за одно SMS на 0.5 руб. ниже чем у amazon)
Также выложил код на GitHub
В данном случае SMS выступает в виде транспорта для доставки одноразового пароля.
Соответственно если использовать другой тип пароля (генерации пароля и пр), вам нужно его сначала сгенерировать в send_authcode(), потом передать пользователю и потом проверить, что вернулось от него в autorize().
Но необходимости в этом особого не вижу, потому что гораздо легче рвать неподтвержденное, например в течении одной/двух минут, VPN-соединение по таймауту (сейчас стоит 59 минут)
С лямбдами тоже никаких вопросов — если смогли написать php скрипт, то и на каком-нибудь nodejs / python наваяете, там сложного ничего нет.
Уровень вхождения не мой, а того, кто внедряет мое решение у себя :)
Я изначально делал его не для себя, а для того чтобы отправить ссылку и человек мог скачав два файла все запустить
Вопрос в цене. У того же Тинькофф.мобайл симка с безлимитными sms стоит 49 руб./мес.
Прикрутить к скрипту отправку через платный сервис, тот же smsc.ru / AWS SNS не проблема, но сразу считайте на одну авторизацию -2,5-3 рубля. Поэтому дешевле точно не выйдет.
нестабильного модема, который может отключить оператор
– не совсем правильно поняли. У меня была такая мысль на начальном этапе создания, т.к не было понимания как относятся к этому операторы и какую нагрузку испытывает модем. И исходя из этого были заложены «страховки»
По факту решение оказалось достаточно стабильное если модем использовать нормальный. У меня установлена Sierra Wireless на pci-e в BaseBox2 и уже более полутора лет работает безотказно примерно по 1200 авторизаций в месяц. Плюс через него я отправляю уведомления умного дома, synology и пр… эдакий домашний sms-шлюз. Модемы пробовал разные (Alcatel, 3272, 3372, SIM800L, …)
AWS Cognito / Lambda – другой уровень вхождения и опять таки цена каждой авторизации…
Pritunl – это облачное решение, для его работы нужно либо VPS в облаке, либо выделять сервер/ВМ + стоимость на каждую авторизацию
Мое решение подходит тем, у кого в парке есть физические маршрутизаторы MT. Сайт, на который можно кинуть скрипт и так у всех (почти у всех) есть.
session-timeout не хорошо использовать по нескольким причинам:
1. необходимость переподключения раз в час будет бесить сотрудников
2. ненужная нагрузка на модемы
3. очень плохо на каналах сервер-mikrotik / mikrotik-mikrotik
В данной статье не говорится про настройку VPN сервера.
Настройка PPP/L2TP/SSTP – это на ответсвенности администратора сети, также как и настройка firewall, которую каждый делает на свой вкус и потребности, на функционале авторизации и её защищенности это никак не сказывается.
Мой скрипт работает при любом типе туннеля, а, например, SSTP не работает use-encryption
Лично я вообще люблю L2TP, вот просто люблю :)
… сервис авторизации нужно выставить в Интернет. Это может быть нежелательно в ряде случаев.
Да, но мы делаем все возможные проверки на предмет неверного запроса. Во вторых, чтобы взломать защиту на этапе авторизации нужно обладать верным номером ruid и верным кодом авторизации. Вариант подбора очень низок.
Ну и самое главное – это единственные способ, который пришел в голову для авторизации соединения Сервер -> Mikrotik
PS в скриптах везде указан http (т.к откатывался в локальной сети), но в жизни нужно https (меняется в 3х местах)
Если у вас есть какие-то подозрения, где можно что-то перехватить, то пишите, покопаем в этом направлении.
1хN подразумевает именно использование одного SMS-шлюза для авторизации на N-vpn, а не сервиса/сервера авторизации (usb-модем в одном роутере, а не в каждом).
– Репликация /ppp secrets не имеет смысла, т.к пользователю должен быть выдан ip из внутренней адресации роутера.
– Использование стороннего радиуса не рассматривалось в данной задаче, как усложняющее «уровень входа» (проще уже было использовать usermanager)
– Данное решение несет функцию защиты внутренней сети компании, а не способы авторизации, а учитывая, что сервис не предназначен для авторизации широкого круга лиц, эти логины добавляются на необходимый MikroTik системным администратором.
p.s. если VPN-соединение сможет провисеть час, то не прошедший проверку клиент всё равно получит доступ к внутренним ресурсам сети.
Не сможет. Через 59 минут соединение будет разорвано по тайм-ауту. Если боязно, то можно не удалять его ip из адресного листа по тайм-ауту (удалив скрипт из On Down). В этом случае адресный лист будет действовать даже после отключения пользователя.
Если же пользователь инициирует новое подключение, то в текущем листе просто обновится код авторизации и все продолжит работать как и запланировано.
Они не соединены, а наоборот – PEN проводник разделен на PE и N.
У вас немного не правильный взгляд на порядок подключения.
Сначала вы написали про вводной 3х полюсный автомат (вроде сейчас все решили), а теперь пишите про реле напряжения.
Реле напряжения в любом случае ставится после вводного автомата, а учитывая что в данной схеме оно есть, то у автора все нормально.
– Добавлена отправка кодов в Synology Chat и через Telegram Bot
– Возможность отправки различным пользователям по различным каналам
– Упрощен код скрипта для MikroTik
Я вас правильно понял. На маке тоже можно не ставить галочку "отправлять весь трафик через vpn".
Но речь у вас изначально была про невозможность на смартфонах пустить трафик не over vpn, вот я говорю, что проблема локальная для l2tp и его реализации в смартфонах. И проблема тут не в микротах.
Тут «от каждого по желаниям, каждому по потребностям». Лично для меня отсутствие OVPN UDP не является причиной, чтобы отказываться от столь мощного оборудования.
Это из разряда извечных споров типа «Android/iOS», «Windows/MacOS», «Huyndai/VW» etc…
Но это решение для рабочего процесса:
– у меня оно используется для авторизации туннелей сервер-микротик и между микротиками, а дальше поднимаю адресацию по OSPF.
– достаточно хорошо будет для авторизации сотрудников работающих на удаленке с компьютера. Я полагаю с телефона никто не работает.
– При соединении офисов в единую сеть данное решение также позволит получать информацию о «падении/подъеме» туннеля. Но это больше вторично, но тоже полезно
И, что не маловажно, если вы/компания строите защищенную сеть и заморочились с 2FA, то шлюз у вас должен быть один, в противном случае в вашу сеть запросто можно зайти, что называется «со двора» – с того устройства у которого основной шлюз не через vpn
SMS взломать не получится, т.к отправленный код действует ровно столько сколько действует сессия установленная в idle-timeout. Далее код теряет свою актуальность.
Поэтому если нужна очень высокая защищенность, для критических узлов можно установить timeout vpn-соединения равным 60s.
Заказать дубликат симки даже за час не реально, учитывая то, что еще нужно знать на какой номер отправлялось сообщение и как-то решить вопрос с предоставляемыми документами для заказа дубликата.
Второй момент – для компаний которые используют для защищенного общения внутренние чаты, например тот же Synology Chat, скрипт может отправлять код авторизации через его API и в этом случае система авторизации становится изолированной от внешней среды.
Вот про это я и писал, что у пользователя должен быть токен или приложение, а также на сервере должна быть форма в которую будет выводиться этот код. В данном случае код не нужно передавать пользователю, но наоборот сервер его должен получить от пользователя. Экономия на смс, но неудобство для авторизации. На мой взгляд гораздо проще перейти по ссылке из SMS/email и пр.
Решение задачи с ТОТР усложняется, когда один пользователь может авторизовать несколько туннелей на разных роутерах (возможность заложена в скрипте).
Да я это понял.
Где он у него будет генерироваться?
Ну или приложение, которое генерирует код и отправляет его на сервер «невидимо».
TOTP в моем понимании – метод шифрования пароля со сроком действия. Сгенерировать его можно на сервере, в клиентском приложении или на токене (например), куда изначально уже внесен ключ-секрет. Если у клиента нет приложения или токена и пароль генерировался на сервере, то пароль ему в любом случае нужно передать.
Если написать приложение, то это все меняет, но я увы не пишу их.
Буду рад любым разъяснениям. Может это то, что индустрия ждет и я это реализую на благо сообщества :)
Я обновил код добавив возможность отправки SMS через платный шлюз, на примере smsc.ru (цена за одно SMS на 0.5 руб. ниже чем у amazon)
Также выложил код на GitHub
Соответственно если использовать другой тип пароля (генерации пароля и пр), вам нужно его сначала сгенерировать в send_authcode(), потом передать пользователю и потом проверить, что вернулось от него в autorize().
Но необходимости в этом особого не вижу, потому что гораздо легче рвать неподтвержденное, например в течении одной/двух минут, VPN-соединение по таймауту (сейчас стоит 59 минут)
Уровень вхождения не мой, а того, кто внедряет мое решение у себя :)
Я изначально делал его не для себя, а для того чтобы отправить ссылку и человек мог скачав два файла все запустить
Прикрутить к скрипту отправку через платный сервис, тот же smsc.ru / AWS SNS не проблема, но сразу считайте на одну авторизацию -2,5-3 рубля. Поэтому дешевле точно не выйдет.
– не совсем правильно поняли. У меня была такая мысль на начальном этапе создания, т.к не было понимания как относятся к этому операторы и какую нагрузку испытывает модем. И исходя из этого были заложены «страховки»
По факту решение оказалось достаточно стабильное если модем использовать нормальный. У меня установлена Sierra Wireless на pci-e в BaseBox2 и уже более полутора лет работает безотказно примерно по 1200 авторизаций в месяц. Плюс через него я отправляю уведомления умного дома, synology и пр… эдакий домашний sms-шлюз. Модемы пробовал разные (Alcatel, 3272, 3372, SIM800L, …)
AWS Cognito / Lambda – другой уровень вхождения и опять таки цена каждой авторизации…
Pritunl – это облачное решение, для его работы нужно либо VPS в облаке, либо выделять сервер/ВМ + стоимость на каждую авторизацию
Мое решение подходит тем, у кого в парке есть физические маршрутизаторы MT. Сайт, на который можно кинуть скрипт и так у всех (почти у всех) есть.
1. необходимость переподключения раз в час будет бесить сотрудников
2. ненужная нагрузка на модемы
3. очень плохо на каналах сервер-mikrotik / mikrotik-mikrotik
Настройка PPP/L2TP/SSTP – это на ответсвенности администратора сети, также как и настройка firewall, которую каждый делает на свой вкус и потребности, на функционале авторизации и её защищенности это никак не сказывается.
Мой скрипт работает при любом типе туннеля, а, например, SSTP не работает use-encryption
Лично я вообще люблю L2TP, вот просто люблю :)
Но спасибо, добавлю пояснения к статье
Да, но мы делаем все возможные проверки на предмет неверного запроса. Во вторых, чтобы взломать защиту на этапе авторизации нужно обладать верным номером ruid и верным кодом авторизации. Вариант подбора очень низок.
Ну и самое главное – это единственные способ, который пришел в голову для авторизации соединения Сервер -> Mikrotik
PS в скриптах везде указан http (т.к откатывался в локальной сети), но в жизни нужно https (меняется в 3х местах)
Если у вас есть какие-то подозрения, где можно что-то перехватить, то пишите, покопаем в этом направлении.
– Репликация /ppp secrets не имеет смысла, т.к пользователю должен быть выдан ip из внутренней адресации роутера.
– Использование стороннего радиуса не рассматривалось в данной задаче, как усложняющее «уровень входа» (проще уже было использовать usermanager)
– Данное решение несет функцию защиты внутренней сети компании, а не способы авторизации, а учитывая, что сервис не предназначен для авторизации широкого круга лиц, эти логины добавляются на необходимый MikroTik системным администратором.
Не сможет. Через 59 минут соединение будет разорвано по тайм-ауту. Если боязно, то можно не удалять его ip из адресного листа по тайм-ауту (удалив скрипт из On Down). В этом случае адресный лист будет действовать даже после отключения пользователя.
Если же пользователь инициирует новое подключение, то в текущем листе просто обновится код авторизации и все продолжит работать как и запланировано.
Они не соединены, а наоборот – PEN проводник разделен на PE и N.
У вас немного не правильный взгляд на порядок подключения.
Сначала вы написали про вводной 3х полюсный автомат (вроде сейчас все решили), а теперь пишите про реле напряжения.
Реле напряжения в любом случае ставится после вводного автомата, а учитывая что в данной схеме оно есть, то у автора все нормально.