В тривиальном случае с каналом до зарубежа — видится некоторая уязвимость в том, что очевидно где сам сервер, делай с ним чего хочешь: ковыряй, собирай данные, ддось. Тут-то и возникла идея сделать решение непрозрачным, распределенным. Идея сама по себе здоровая?
Ну про AWS и Azure тут еще можно поспорить. Задача ведь на самом деле — максимально затруднить вычисление местоположения серверов. Если сервер размещен в AWS или Azure — его вычислять не нужно и так понятно где он. Можно включать админресурс, социнжениринг, классический набор атак на облака. Релейные серверы можно брать в вышеуказанных местах, но не сам защищаемый сервер.
Идея хорошая, спасибо, буду помнить, что надо от нее закрываться. В данном экспериментально случае — сработало. На практике же, открытые сервисы будут с авторизацией и разнесены по точкам доступа по географическому и функциональному принципам, значит в боевых условиях zmap будет не эффективен.
Точки, они же релей сервера, являются узлами подключения пользователей к сервисам. Они с одной стороны, точки доступа пользователей к защищенному серверу, а с другой стороны отдают "стандартные сервисы". Сегодня, в качестве сервиса опубликован web сайт.
Метод по Маркову — скорее всего малореален, ведь с одной стороны мы предполагаем, что клиенты чаще будут использовать серверы, размещенные вне пределов РФ, не нарушая при этом никаких ФЗ, а СОРМ будет эффективен в случае, если большая часть инфраструктуры находится на территории РФ. Да и если паяльник пойдет в ход, никакие сложные математические методы не понядобятся.
А вообще, у нас была идея собрать систему защиты IT-ресурсов от киберразведки и направленных атак. Киберразведка — в понимании как деятельность, имеющая своей целью получение доступа, сбор и анализ определенной информации, в рамках которой, могут эксплуатироваться любые известные уязвимости, множественные ложные запросы, анализаторы трафика, ну и конечно социальная инженерия с административными ресурсами.
Как видится, одним из факторов, существенно усложняющим киберразведку является невычисляемость адреса расположения сервера, так как в этом случае, сужаются возможности социально-инженерных и административных приемов.
Согласен, хорошая идея. Есть только вопрос, как быть с обеспечением IP-spoofing. Ведь при при тиражировании решения на большое количество клиентов, есть опасение однажды столкнуться с шквальными обрывами, что если какой-нить провайдер запретит такие подмены адресов. Не выглядит ли решение, когда пакеты в обратном направлении проходят через те же узлы немного стабильнее?
На самом деле, в нашем случае, это конечно не винда ;), ну да это не важно, сервис клиента может быть любым :).
Про архитектуру, верно, OpenVPN (ну или аналоги) через TOR вполне себе должны работать, есть только два сомнения:
1) Как быть с производительностью, клиентосы-то на практике не довольны, как тут быть?
2) На первый взгляд, если в процесс начнет встревать геополитика, TOR отрубать будут с большим усердием и для поддержки этого решения в стабильном состоянии понадобится больше компетенций и усилий админа, это для нас тоже открытый вопрос.
В действительности, хотим сделать что-то вроде коробки, которая не требует своего сильноразвитого и дорогого админа. Плюс всякие фишки с управлением в удобном дашборде.
Нам ведь нужно обеспечивать географическую распределенность между узлами… Так при чем тут спуффинг, мы же не в одной локальной сети… а если про L2 VPN… да, это возможно, но все равно нужна обертка, откидывающая IP адрес куда-то подальше, да и не каждый провайдер разрешит заниматься спуффингом. Что имеется в виду?
Работать со своим облачным сервером через общедоступные сервисы обеспечивающие анонимность — один из вариантов, теоретически максимально близких по уровню защищенности. Основных различия два:
1) Вы никогда не получите гарантированный, подконтрольный вам уровень скорости работы. Чем сложнее и надежнее публичная система, тем медленее и непредсказуемее она работает, а спрогнозировать ее производительность не представляется возможным.
2) Вы никогда не получите гарантированный и подконтрольный только клиенту уровень конфиденциальности, все публичный системы с определенной долей вероятности могут быть скомпромитированны.
А еще, TOR из практики наших клиентов все-таки тормозной, слишком часто для корп пользователей рвет соединения и сложный в настройке. А продолбать TOR соединение и выпустить трафик незавернутым в VPN — как нефиг делать. Ну и вопрос доверия: доверяешь ли ты миллионам пользователей TOR или хочешь иметь свою собственную распределенную сеть. В socks-proxy не всякое приложение засунешь, плюс известная проблема с UDP и костыли для ее решения. Например, SIP вообще в TOR не заведешь.
LVS мы тоже готовы использовать внутри периметра для распределения нагрузки между серверами, но не в качестве альтернативы самой системы безопасности. Архитектурно, LVS совмещает в себе функции и релей сервера и сервера маршрутизации и соответственно в нем отсутствует дополнительный уровень анонимности. Разница в том, что с нашего релей сервера нельзя узнать IP роутера, а с роутера нельзя узнать IP защищенных им серверов.
Совершенно верно, тыкать в опубликованный сервис клиента — самый прямой способ обнаружить сервер. Поэтому всегда очень дотошно следует разбираться в сервисах клиента на предмет настроек безопасности.
Пользователям должны быть зарезаны права на просмотр служебной конфигурационной информации сервера, для RDP это IP и Mac адреса, ключи лицензий и т.п.
По архитектуре, трафик всех сервисов клиента всегда идет только в направлении сервера маршрутизации. То есть весь трафик RDP сессии всегда пройдет через роутер и какую-либо релей точку, IP которой и засветится.
Почта один из сложных сервисов, поэтому мы рекомендуем клиентам использовать браузерный доступ к внешней почте, который пробрасывается через отдельную релей точку доступа.
На данном этапе хочется понять, правильная ли идея с архитектурой. Естественно, когда это станет продуктом (если станет), я поставлю и хорошие bug bounty. Не уровня Facebook, но хорошие.
Какой технотренд на год-два вперед?
Точки, они же релей сервера, являются узлами подключения пользователей к сервисам. Они с одной стороны, точки доступа пользователей к защищенному серверу, а с другой стороны отдают "стандартные сервисы". Сегодня, в качестве сервиса опубликован web сайт.
Как на счет самого сервера?
А вообще, у нас была идея собрать систему защиты IT-ресурсов от киберразведки и направленных атак. Киберразведка — в понимании как деятельность, имеющая своей целью получение доступа, сбор и анализ определенной информации, в рамках которой, могут эксплуатироваться любые известные уязвимости, множественные ложные запросы, анализаторы трафика, ну и конечно социальная инженерия с административными ресурсами.
Как видится, одним из факторов, существенно усложняющим киберразведку является невычисляемость адреса расположения сервера, так как в этом случае, сужаются возможности социально-инженерных и административных приемов.
Про архитектуру, верно, OpenVPN (ну или аналоги) через TOR вполне себе должны работать, есть только два сомнения:
1) Как быть с производительностью, клиентосы-то на практике не довольны, как тут быть?
2) На первый взгляд, если в процесс начнет встревать геополитика, TOR отрубать будут с большим усердием и для поддержки этого решения в стабильном состоянии понадобится больше компетенций и усилий админа, это для нас тоже открытый вопрос.
В действительности, хотим сделать что-то вроде коробки, которая не требует своего сильноразвитого и дорогого админа. Плюс всякие фишки с управлением в удобном дашборде.
1) Вы никогда не получите гарантированный, подконтрольный вам уровень скорости работы. Чем сложнее и надежнее публичная система, тем медленее и непредсказуемее она работает, а спрогнозировать ее производительность не представляется возможным.
2) Вы никогда не получите гарантированный и подконтрольный только клиенту уровень конфиденциальности, все публичный системы с определенной долей вероятности могут быть скомпромитированны.
А еще, TOR из практики наших клиентов все-таки тормозной, слишком часто для корп пользователей рвет соединения и сложный в настройке. А продолбать TOR соединение и выпустить трафик незавернутым в VPN — как нефиг делать. Ну и вопрос доверия: доверяешь ли ты миллионам пользователей TOR или хочешь иметь свою собственную распределенную сеть. В socks-proxy не всякое приложение засунешь, плюс известная проблема с UDP и костыли для ее решения. Например, SIP вообще в TOR не заведешь.
Пользователям должны быть зарезаны права на просмотр служебной конфигурационной информации сервера, для RDP это IP и Mac адреса, ключи лицензий и т.п.
По архитектуре, трафик всех сервисов клиента всегда идет только в направлении сервера маршрутизации. То есть весь трафик RDP сессии всегда пройдет через роутер и какую-либо релей точку, IP которой и засветится.
Почта один из сложных сервисов, поэтому мы рекомендуем клиентам использовать браузерный доступ к внешней почте, который пробрасывается через отдельную релей точку доступа.