Энтепрайзное сесурити

Придерживаетесь открытых стандартов и опенсорса?

Если бы это обеспечивало реальную безопасность - придерживался бы

Ну как реальную. Цитрикс и гугл 2fa отключаются одним кликом корпораций добра или родным РКН. «Немодные» l2tp с ipsec и обычный RDP лишены хотя бы этого недостатка.

Верх маразма это винду с непорезанным доступом в инет (внешним файрволлом) использовать для чего-то серьёзного. Как там доступ организован уже не так важно.

«Немодные» l2tp с ipsec и обычный RDP лишены хотя бы этого недостатка.

Нужно ssh вместо всего перечисленного. Дальше через него можно пробросить x11/vnc/rdp на выбор, если нужно гуи.

возьми вместо гугла любой другой генератор OTP, зачем этот баттхёрт?

В твоей компании работают кретины. Увольняйся.

так он повышает % кретинов в компании и лично для себя создает прецедент убегания от проблемы, которая всегда догонит

Tunnel through SSH with Rutoken ECP2/3 или другие криптотокены,

остальное IMHO такое себе, до очередной найденной дыры.

Кто занимается этим, говорят не секурно и не энтерпрайзно.

Фаервол порезан по отдельным ip и портам даже внутри организации с запросом доступа у СБ. Винда там, где используется, необходима для работы. Кому не нужно, сидят на убунте/дебиане.

Что такое google 2fa? Одноразовые тридцатисекундные пароли? Это хоть и носит неофициальное название google authenticator, по факту подойдёт любой OTP клиент, стандарт открытый и предельно простой.

В экономике тоже есть естественный отбор, не мешай ему

UDP сквозь SSH, офигительная идея.

UDP сквозь SSH, офигительная идея.

UDP для чего?

Но в SSH есть ведь и tun, который может легко туннелировать любой IP трафик, т.е. выше либо равно L3.

https://wiki.archlinux.org/title/VPN_over_SSH

А если тебе приспичит туннелировать L2, то можно пробросить через SSH и OpenVPN в TCP mode с TAP интерфейсами для внутреннего туннеля, эффективность с точки зрения производительности конечно сомнительная, зато вероятно секурно при использовании аппаратного крипто (для аутентификации) с обоих сторон SSH (на клиенте и сервере) :)

UDP для чего?

Мало ли для чего. Это ты предлагаешь SSH на замену L2TP и IPSEC.

Но в SSH есть ведь и tun

Я знаю, что есть. Я даже однажды кофигурировал VPN сервер на основе SSH. Я к тому что туннелировать UDP через TCP - сомнительная идея. Вот если бы SSH умел использовать транспорт на основе UDP, тогда другое дело. Почему никто такого ещё не придумал?

Мало ли для чего. Это ты предлагаешь SSH на замену L2TP и IPSEC.

Вроде не на замену, а как вариант.

Туннель, проброшенный через OpenSSH, имеет свойство регулярно отваливаться в случае вредного провайдера, а без особых настроек даже autossh будет достаточно долго тупить до следующего реконнекта.

Вот если бы SSH умел использовать транспорт на основе UDP, тогда другое дело. Почему никто такого ещё не придумал?

Не важно какой там транспорт. Протокол строго последовательный, так что получится всё равно юзерспейсный TCP.

А зачем туннелировать UDP, сохраняя ему датаграмные артефакты, я тоже не понимаю.

сохраняя ему датаграмные артефакты

Что? Какие артефакты?

https://f-droid.org/en/packages/com.beemdevelopment.aegis/ нафиг тебе гугл?

можно в разгар айтишных санкций перевести удалённые рабочие столы на Citrix с гугловской 2FA.

google authenticator - просто програмный ota, он не обращается к гуглу.

Citrix - удобная в администрировании self-hosted система для виртуализации поверх Xen.

Не вижу ничего страшного.

У меня 2FA на ssh jump host стоит в дополнение к ключу с паролем.

Это когда приложение видит поздний пришедший пакет но не видит более ранний.

Вот прямо сейчас мой работодатель переходит с собственных серверов ipsec и l2tp для RDP на OpenVPN с 2FA через сторонние сервисы. Потому что l2tp либо ipsec взломали.

И? В чём твоя проблем с этим? Для некоторых приложений такое поведение может быть необходимо. Потери пакетов могут не иметь значения, если они не высоки, а предыдущий пакет может быть уже неактуален после получения следующего.

Не то что бы проблема, но мало кому захочется заморачиваться ради такого редко нужного случая, когда можно просто обернуть всё в потоковый протокол без особых оверхедов. А так данные выгоднее слать сразу большими пакетами, не зависящими от приложения, в том же потоке что и всякую служебную информацию протокола, и терять их этом случае нельзя. Ну и CBC режимы всякие не получится использовать если потерять данные в середине.

такого редко нужного случая

Не такой уж и редкий. Почти все онлайн игры (кроме пошаговых).

Да, самое то в какой-нить контр-страйк через шифрованный туннель играть. Я предполагал что туннель всё-таки для чего-то серьёзного.

И кстати, если не считать игр на quake / half-life / hl2 движках и их форках - то я совсем не уверен что там UDP массово испольуется.

Статистика игр,в которые я играл, говорит как раз об обратном.

Потому что l2tp либо ipsec взломали.

Так взломали скорее всего не ваш IPSEC, а всего лишь сперли ваш ключ, который вы не потрудились спрятать в аппаратном криптотокене? Но виноват конечно же IPSEC :)

Расследование не завершено, но предполагают, что проблема в ком-то из пользователей с правами админа :)

Поэтому выходит, что сторонние решения безопаснее. Там правила заданы жёстче. И послабления делать нельзя.

Поэтому выходит, что сторонние решения безопаснее. Там правила заданы жёстче. И послабления делать нельзя.

Жестче, - это когда ничего серьезного нельзя сделать без подтверждения нескольких Security Officers, как в Nitrokey HSM2.

Жестче, - это когда ничего серьезного нельзя сделать без подтверждения нескольких Security Officers

Именно.