Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 91
Один из способов атаки — заставить "защищаемый сервер клиента" сообщить наружу свой айпи адрес любым способом. Зависит конечно от того, что пользователи могут делать на нём и какие задачи выполнять.
Например в первом случае, где РДП ферма. Если юзер откроет в РДП сессии браузер и оттуда зайдёт на адрес атакующего — как пойдёт трафик?
Если трафик пойдёт через центральный маршрутизатор, и нигде не будет указан айпи адрес фермы, то всё ок. Иначе — сами понимаете :)
Второй способ — почта :) Как идёт отправка почты (и вообще все подобные автоматические сервисы) с сервера-фермы? Если используется какой либо смтп сервер — то насколько хорошо он скрывает оригинальный айпи адрес? А то много чего можно найти в служебных заголовках.
Например в первом случае, где РДП ферма. Если юзер откроет в РДП сессии браузер и оттуда зайдёт на адрес атакующего — как пойдёт трафик?
Если трафик пойдёт через центральный маршрутизатор, и нигде не будет указан айпи адрес фермы, то всё ок. Иначе — сами понимаете :)
Второй способ — почта :) Как идёт отправка почты (и вообще все подобные автоматические сервисы) с сервера-фермы? Если используется какой либо смтп сервер — то насколько хорошо он скрывает оригинальный айпи адрес? А то много чего можно найти в служебных заголовках.
Совершенно верно, тыкать в опубликованный сервис клиента — самый прямой способ обнаружить сервер. Поэтому всегда очень дотошно следует разбираться в сервисах клиента на предмет настроек безопасности.
Пользователям должны быть зарезаны права на просмотр служебной конфигурационной информации сервера, для RDP это IP и Mac адреса, ключи лицензий и т.п.
По архитектуре, трафик всех сервисов клиента всегда идет только в направлении сервера маршрутизации. То есть весь трафик RDP сессии всегда пройдет через роутер и какую-либо релей точку, IP которой и засветится.
Почта один из сложных сервисов, поэтому мы рекомендуем клиентам использовать браузерный доступ к внешней почте, который пробрасывается через отдельную релей точку доступа.
Пользователям должны быть зарезаны права на просмотр служебной конфигурационной информации сервера, для RDP это IP и Mac адреса, ключи лицензий и т.п.
По архитектуре, трафик всех сервисов клиента всегда идет только в направлении сервера маршрутизации. То есть весь трафик RDP сессии всегда пройдет через роутер и какую-либо релей точку, IP которой и засветится.
Почта один из сложных сервисов, поэтому мы рекомендуем клиентам использовать браузерный доступ к внешней почте, который пробрасывается через отдельную релей точку доступа.
А чем LVS не подошел?
LVS мы тоже готовы использовать внутри периметра для распределения нагрузки между серверами, но не в качестве альтернативы самой системы безопасности. Архитектурно, LVS совмещает в себе функции и релей сервера и сервера маршрутизации и соответственно в нем отсутствует дополнительный уровень анонимности. Разница в том, что с нашего релей сервера нельзя узнать IP роутера, а с роутера нельзя узнать IP защищенных им серверов.
Вариант со спуфингом чем не анонимен?
Какой сценарий атаки предполагается?
Даже не представляю, ну вернее представляю, но от этих вариантов у вашей схемы тоже нет защиты, tor да, поможет и от таких вариантов. Просто вариант с lvs пилится на коленке за полчаса, ну отсюда и вопрос, чем вариант lvs + spoofing вас не устраивает, в чем он менее защищен?
Нам ведь нужно обеспечивать географическую распределенность между узлами… Так при чем тут спуффинг, мы же не в одной локальной сети… а если про L2 VPN… да, это возможно, но все равно нужна обертка, откидывающая IP адрес куда-то подальше, да и не каждый провайдер разрешит заниматься спуффингом. Что имеется в виду?
Вариант lvs-tun(вроде, проверять по документации лень), работал у меня в проде году так в 2005, скрывал файлохранилище на 100 терабайт, трафик около 4 — 5 гигабит, усредненный. Публичные точки были в штатах, европе. Где было ядро не актуально. В общем почитайте документацию lvs, там много забавного и интересного. По сути ваш кэйс покрывается этим по полностью. Без велосипедов. Есть ограничения, провайдер должен разрешать spoofing, но это решаемо.
Согласен, хорошая идея. Есть только вопрос, как быть с обеспечением IP-spoofing. Ведь при при тиражировании решения на большое количество клиентов, есть опасение однажды столкнуться с шквальными обрывами, что если какой-нить провайдер запретит такие подмены адресов. Не выглядит ли решение, когда пакеты в обратном направлении проходят через те же узлы немного стабильнее?
За пару лет, ни разу не столкнулся с такой проблемой. В общем нет такой проблемы.
Я в своих сетях запрещаю на выход IP не входящие в анонсы маршрутизатора и очень многие делают именно так, это же прописано во всех рекомендациях, странно что не сталкивались, я регулярно натыкаюсь, когда заводишь к себе новую сеть, потом чтоб ускорить автоматику начинаешь пинать вышестоящих магистралов чтоб вручную протащили сеть через фильтры.
Попытка изобрести доморощенный TOR.
Просто поднимите tor, засуньте виндовый сервер за socks-proxy tor'а — и всё, сервер сокрыт. Современных скоростей tor'а достаточно для всех практических нужд.
Просто поднимите tor, засуньте виндовый сервер за socks-proxy tor'а — и всё, сервер сокрыт. Современных скоростей tor'а достаточно для всех практических нужд.
Скорость там достаточная, но задержки большие — комфортной работы по RDP не будет
На устоявшемся соединении? Вполне терпимо. Вот рваться будет иногда — это да.
Стабильно: раз в 10 минут.
При этом рвётся нижележащий уровень, а для вышележащего туннеля это всего лишь лаг в работе.
Верно, а есть способ эти задержки снизить?
Какой технотренд на год-два вперед?
Какой технотренд на год-два вперед?
Чисто теоретически, можно попробовать иметь два асинхронных соединения с быстрым failover'ом или даже дупликацией пересылаемых данных (кто быстрее — того и тапки).
Вообще, интересная тема для абстрактного CS проекта: как имея два или более tcp-соединения с неизвестными и неровными задержками получить сервис с меньшей latency.
Вообще, интересная тема для абстрактного CS проекта: как имея два или более tcp-соединения с неизвестными и неровными задержками получить сервис с меньшей latency.
Как мне кажется, этакую приватную onion сеть можно и на своей инфраструктуре поднять. На тех-же самых серверах "точек доступа". Поправьте если я не прав.
Работать со своим облачным сервером через общедоступные сервисы обеспечивающие анонимность — один из вариантов, теоретически максимально близких по уровню защищенности. Основных различия два:
1) Вы никогда не получите гарантированный, подконтрольный вам уровень скорости работы. Чем сложнее и надежнее публичная система, тем медленее и непредсказуемее она работает, а спрогнозировать ее производительность не представляется возможным.
2) Вы никогда не получите гарантированный и подконтрольный только клиенту уровень конфиденциальности, все публичный системы с определенной долей вероятности могут быть скомпромитированны.
А еще, TOR из практики наших клиентов все-таки тормозной, слишком часто для корп пользователей рвет соединения и сложный в настройке. А продолбать TOR соединение и выпустить трафик незавернутым в VPN — как нефиг делать. Ну и вопрос доверия: доверяешь ли ты миллионам пользователей TOR или хочешь иметь свою собственную распределенную сеть. В socks-proxy не всякое приложение засунешь, плюс известная проблема с UDP и костыли для ее решения. Например, SIP вообще в TOR не заведешь.
1) Вы никогда не получите гарантированный, подконтрольный вам уровень скорости работы. Чем сложнее и надежнее публичная система, тем медленее и непредсказуемее она работает, а спрогнозировать ее производительность не представляется возможным.
2) Вы никогда не получите гарантированный и подконтрольный только клиенту уровень конфиденциальности, все публичный системы с определенной долей вероятности могут быть скомпромитированны.
А еще, TOR из практики наших клиентов все-таки тормозной, слишком часто для корп пользователей рвет соединения и сложный в настройке. А продолбать TOR соединение и выпустить трафик незавернутым в VPN — как нефиг делать. Ну и вопрос доверия: доверяешь ли ты миллионам пользователей TOR или хочешь иметь свою собственную распределенную сеть. В socks-proxy не всякое приложение засунешь, плюс известная проблема с UDP и костыли для ее решения. Например, SIP вообще в TOR не заведешь.
В tor заворачиваются потоковые каналы. На бытовом уровне ssh и tor позволяют завернуть любой трафик (tun/tap туннель через ssh через tor), на промышленном уровне — openvpn@tcp через тот же tor. Network namespaces позволяют ограничить видимость сетевых интерфейсов и исключить любые утечки. Вы же винду виртуалкой на линуксовом сервере держите, правда?
Пользователям TOR'а доверять не нужно — не для этого он задумывался. Компрометация публичной системы (релея) ничего не ухудшит в работе TOR'а, если только не скомпрометированы все узлы из машрута.
Пользователям TOR'а доверять не нужно — не для этого он задумывался. Компрометация публичной системы (релея) ничего не ухудшит в работе TOR'а, если только не скомпрометированы все узлы из машрута.
На самом деле, в нашем случае, это конечно не винда ;), ну да это не важно, сервис клиента может быть любым :).
Про архитектуру, верно, OpenVPN (ну или аналоги) через TOR вполне себе должны работать, есть только два сомнения:
1) Как быть с производительностью, клиентосы-то на практике не довольны, как тут быть?
2) На первый взгляд, если в процесс начнет встревать геополитика, TOR отрубать будут с большим усердием и для поддержки этого решения в стабильном состоянии понадобится больше компетенций и усилий админа, это для нас тоже открытый вопрос.
В действительности, хотим сделать что-то вроде коробки, которая не требует своего сильноразвитого и дорогого админа. Плюс всякие фишки с управлением в удобном дашборде.
Про архитектуру, верно, OpenVPN (ну или аналоги) через TOR вполне себе должны работать, есть только два сомнения:
1) Как быть с производительностью, клиентосы-то на практике не довольны, как тут быть?
2) На первый взгляд, если в процесс начнет встревать геополитика, TOR отрубать будут с большим усердием и для поддержки этого решения в стабильном состоянии понадобится больше компетенций и усилий админа, это для нас тоже открытый вопрос.
В действительности, хотим сделать что-то вроде коробки, которая не требует своего сильноразвитого и дорогого админа. Плюс всякие фишки с управлением в удобном дашборде.
До момента бана тора должно пройти какое-то время. Переключение underlaying протокола для openvpn — не велика работа. В тривиальном виде — это любой канал до сервера зарубежом. Конечно, дойдёт очередь и до каналов до серверов зарубежом, и до выездных виз. Но — всему своя очередь. Пока что можно резвиться таким образом.
В тривиальном случае с каналом до зарубежа — видится некоторая уязвимость в том, что очевидно где сам сервер, делай с ним чего хочешь: ковыряй, собирай данные, ддось. Тут-то и возникла идея сделать решение непрозрачным, распределенным. Идея сама по себе здоровая?
Ну, это tor и есть. А за жопку брать будут не отслеживая ip'шники и трекая сервера в разных странах, а по финансовым операциям.
Для совершенного уровня надо использовать bitcoin через tor, да ещё серьёзно задуматься о методе ввода средств, т.к. все операции в bitcoin хорошо видны в блокчейне. Миксеры, биржи и всё такое. И одноразовые кошельки для оплаты.
Для совершенного уровня надо использовать bitcoin через tor, да ещё серьёзно задуматься о методе ввода средств, т.к. все операции в bitcoin хорошо видны в блокчейне. Миксеры, биржи и всё такое. И одноразовые кошельки для оплаты.
Как тут верно заметили ранее — самый действенный способ используя что-то типа Server-Side-Request-Forgery (SSRF) заставить сервер постучаться куда надо, тем самым деанонимизировав себя.
Другой интересный вопрос, как заставить виндовый сервер на IIS8, отдающий бездушный статический html без кнопочек и формочек, сделать это :)
Другой интересный вопрос, как заставить виндовый сервер на IIS8, отдающий бездушный статический html без кнопочек и формочек, сделать это :)
Решал задачку, похожую на задачку автора. Делал точку входа на сервере на Linux, точку выхода на сервера на Linux и сервер приложений на linux+vmware (тогда еще xen,kvm и прочие вещи не совсем мейнстримовыми были)
на сервере приложений была запущена виртуальная машина для роутинга (linux) + виртуальные машины на серых адресах с сервисами (почтой в том числе)
на сервере приложений реальный IP был только у панели управления виртуальными машинами, и виртуальной машины которая занималась только роутингом (iproute2 + openvpn).
Итого схема получалась следующая.
1) Трафик приходит на машину точки входа
2) На точке входа делается DNAT в серый адрес сервиса (например x.x.x.x:25->10.0.0.2:25)
3) По роутингу (через openvpn) трафик уходит в виртуальную машину на сервере приложений
4) С машины роутинга по внутренней сети трафик передается на почтовый сервер
5) Шаги для возврата пакетов аналогичные, за исключением, что вместо DNAT делается SNAT
Для исходящего трафика (с почтового сервера) трафик запускался по другой цепочке и выходил через точку входа;
Итого получали сплошные профиты
1) Так как сервер на серых адресах, то его все равно, что узнают его адрес
2) По точке выхода не возможно определить точку входа.
PS: По желанию можно на входе делать SNAT адреса клиента
на сервере приложений была запущена виртуальная машина для роутинга (linux) + виртуальные машины на серых адресах с сервисами (почтой в том числе)
на сервере приложений реальный IP был только у панели управления виртуальными машинами, и виртуальной машины которая занималась только роутингом (iproute2 + openvpn).
Итого схема получалась следующая.
1) Трафик приходит на машину точки входа
2) На точке входа делается DNAT в серый адрес сервиса (например x.x.x.x:25->10.0.0.2:25)
3) По роутингу (через openvpn) трафик уходит в виртуальную машину на сервере приложений
4) С машины роутинга по внутренней сети трафик передается на почтовый сервер
5) Шаги для возврата пакетов аналогичные, за исключением, что вместо DNAT делается SNAT
Для исходящего трафика (с почтового сервера) трафик запускался по другой цепочке и выходил через точку входа;
Итого получали сплошные профиты
1) Так как сервер на серых адресах, то его все равно, что узнают его адрес
2) По точке выхода не возможно определить точку входа.
PS: По желанию можно на входе делать SNAT адреса клиента
Да, мы тоже по сути эту схему в начале делали с точками "входа", потом поняли, что некоторые виды трафика по условиям задачи нужно отдавать через другие точки "выхода". Типа в сторону gmail трафик один с одного адреса, в сторону сбербанка с другого. Но потом когда задумались о тиражируемой коробке, переработали схему. теперь у нас универсальные "точки доступа" они могут смотреть как в сторону клиента, так и в сторону сервиса.
Отдельная история с NAT когда SIP через него пытаешься гнать, тут мы тоже неслабое число граблей собрали. Но по факту, получили не просто криптофон, а анонимный криптофон, при звонке или чате с которого нельзя, прослушивая трафик, установить даже кому ты звонил или писал.
Еще мы поняли, что чтобы клиенту нужно отдавать сервис без нашего к нему доступа, то есть клиенту отдается коробка, к которой у нас нет ни доступа, но и даже информации о том на каких адресах она работает. Тут пришлось пилить систему управления, легкую и удобную.
Отдельная история с NAT когда SIP через него пытаешься гнать, тут мы тоже неслабое число граблей собрали. Но по факту, получили не просто криптофон, а анонимный криптофон, при звонке или чате с которого нельзя, прослушивая трафик, установить даже кому ты звонил или писал.
Еще мы поняли, что чтобы клиенту нужно отдавать сервис без нашего к нему доступа, то есть клиенту отдается коробка, к которой у нас нет ни доступа, но и даже информации о том на каких адресах она работает. Тут пришлось пилить систему управления, легкую и удобную.
Но при этом, конкретно этот сервер, с незакрытой уязвимостью MS15-034
Тоже нашел эту дырку, но т.к. на фронте nginx, то она не отрабатывает. Сразу попробовал эксплуатировать и вывести ipconfig, но получил обычную 416, так что не критично.
Там перекомпиленный nginx, который в ident отдает "Microsoft-IIS/8.0". Понять можно по 404-й странице, когда страница генерится nginx-ом.
Не факт, либо так либо на фронте nginx с кешированием и ошибками, на бэке действительно Microsoft-IIS/8.0, тут понять сложно так как доступна только статичная страничка с одной картинкой.
Могу ошибаться (а проверять на практике сейчас лениво), но кажется мне, что стандартная 404-я страница nginx говорит про "proxy_intercept_errors on;", а значит страница генерится nginx-ом, но в "Server" указан Microsoft-IIS/8.0, хотя в этом случае должен быть nginx.
Пойду в подтверждение исходники посмотрю, что-ли...
Пойду в подтверждение исходники посмотрю, что-ли...
Смею уверенно утверждать, что ее там нет.
Как вы за оптоволокном скроете IP адреса? И да, тогда уж проще парочку каких-нибудь дальнобойных микротиков, и сервер подальше.
Но опять таки, это немного не тот кейс. У вас скорее кейс для скрытия от контролирующих органов(где рубильник вырубил и всё), здесь-же защита от конкурентов.
Но опять таки, это немного не тот кейс. У вас скорее кейс для скрытия от контролирующих органов(где рубильник вырубил и всё), здесь-же защита от конкурентов.
Название статьи немного многозначительное, простите мой каламбур, но всё-же применение несколько другое, чем описанное в вашем предыдущем комменте. А вот дискредитация внутренней сети, даже за NAT-ом, вещь довольно распространённая. Так что архитектура описанная в статье несколько более защищена от таких атак.
Если там есть какой-нибудь web-сайтик с API, то любая XSS, которая заставит отправить ответ на запрос API на внешний сервер может раскрыть информацию о положении сервера.
Осмелюсь сделать предположение. Испания?
У меня вопрос — от кого защищаетесь?
В вашем случае — все каналы строятся через интернет, что значит — все соединения проходят СОРМ, что значит — если вы реально "кому-то" интересны, то построить граф Макрова или выполнить частотное сравнение полей пакетов (автоматически) не представляет никакой сложности. Т.е. поскольку ваши точки общаются значительно чаще, чем одна из точек и внешний мир, адрес каждой из них не представляет секрета. TOR, кстати, уязвим по этой же причине, при недостаточности энтропии — т.е. большого числа случайных соединений между узлами.
Другими словами хочу сказать следующее: если задача была обезопасить трафик и вынести данные в "условно-безопасную" юрисдикцию, то задача почти решена (никто не отменял паяльник, как писали выше), если же задача была скрыть нахождение сервера (тем более у кого-то дома), то не только вводите себя и клиента в заблуждение, но может и подставляете кого-то физически.
В вашем случае — все каналы строятся через интернет, что значит — все соединения проходят СОРМ, что значит — если вы реально "кому-то" интересны, то построить граф Макрова или выполнить частотное сравнение полей пакетов (автоматически) не представляет никакой сложности. Т.е. поскольку ваши точки общаются значительно чаще, чем одна из точек и внешний мир, адрес каждой из них не представляет секрета. TOR, кстати, уязвим по этой же причине, при недостаточности энтропии — т.е. большого числа случайных соединений между узлами.
Другими словами хочу сказать следующее: если задача была обезопасить трафик и вынести данные в "условно-безопасную" юрисдикцию, то задача почти решена (никто не отменял паяльник, как писали выше), если же задача была скрыть нахождение сервера (тем более у кого-то дома), то не только вводите себя и клиента в заблуждение, но может и подставляете кого-то физически.
Метод по Маркову — скорее всего малореален, ведь с одной стороны мы предполагаем, что клиенты чаще будут использовать серверы, размещенные вне пределов РФ, не нарушая при этом никаких ФЗ, а СОРМ будет эффективен в случае, если большая часть инфраструктуры находится на территории РФ. Да и если паяльник пойдет в ход, никакие сложные математические методы не понядобятся.
А вообще, у нас была идея собрать систему защиты IT-ресурсов от киберразведки и направленных атак. Киберразведка — в понимании как деятельность, имеющая своей целью получение доступа, сбор и анализ определенной информации, в рамках которой, могут эксплуатироваться любые известные уязвимости, множественные ложные запросы, анализаторы трафика, ну и конечно социальная инженерия с административными ресурсами.
Как видится, одним из факторов, существенно усложняющим киберразведку является невычисляемость адреса расположения сервера, так как в этом случае, сужаются возможности социально-инженерных и административных приемов.
А вообще, у нас была идея собрать систему защиты IT-ресурсов от киберразведки и направленных атак. Киберразведка — в понимании как деятельность, имеющая своей целью получение доступа, сбор и анализ определенной информации, в рамках которой, могут эксплуатироваться любые известные уязвимости, множественные ложные запросы, анализаторы трафика, ну и конечно социальная инженерия с административными ресурсами.
Как видится, одним из факторов, существенно усложняющим киберразведку является невычисляемость адреса расположения сервера, так как в этом случае, сужаются возможности социально-инженерных и административных приемов.
Метод по Маркову — скорее всего малореален, ведь с одной стороны мы предполагаем, что клиенты чаще будут использовать серверы, размещенные вне пределов РФ, не нарушая при этом никаких ФЗ, а СОРМ будет эффективен в случае, если большая часть инфраструктуры находится на территории РФ.
Как связан метод, с местоположением серверов,- это же просто математика. Если у вас хотя бы один узел в РФ, то СОРМ не дремлет (при желании), а это значит, что можно составить граф коннектов и полей заголовков, а по большей плотности сразу видны "места наибольших коннектов", т.е. плотность трафика между 2-3-4-5 узлами значительно выше плотности остальных соединений, что приводит к абсолютной деанонимизации всей вашей сети.
А вообще, у нас была идея собрать систему защиты IT-ресурсов от киберразведки и направленных атак. Киберразведка — в понимании как деятельность, имеющая своей целью получение доступа, сбор и анализ определенной информации, в рамках которой, могут эксплуатироваться любые известные уязвимости, множественные ложные запросы, анализаторы трафика, ну и конечно социальная инженерия с административными ресурсами.
Так получается, что задача провалена чуть более, чем полностью, ведь анализатор трафика (тот же пассивный СОРМ, даже без DPI) дает полное и исчерпывающее понимание всей структуры вашей сети.
Как видится, одним из факторов, существенно усложняющим киберразведку является невычисляемость адреса расположения сервера, так как в этом случае, сужаются возможности социально-инженерных и административных приемов.
см. доводы выше. Кроме всего прочего, вы сильно заблуждаетесь в том, что мерами групповых политик и ограничения доступа пользователей к сокрытию информации (как вы писали в комменте ) что-то защищаете. Ведь сокрытие алгоритма, например, не делает алгоритм шифрования устойчивее, иногда даже наоборот (см. работы Шеннона и доказательства стойкости), у вас же средством обеспечения надежности является операционная система, НДВ которой, мягко говоря, не исследовано.
Более правильным было бы создать "виртуальную" сеть, с серой адресацией, строилась бы которая на независимых маршрутизаторах, что вообще избавило бы от проблем настройки конечных пользовательских систем, забывчивости администраторов и, как вы писали, административного ресурса с применением социальной инженерии, т.е. для пользователя систему все выглядело бы как простая внутренняя локальная сеть; вы же, закрывая доступ, вызываете нездоровые вопросы и интерес.
Как связан метод, с местоположением серверов,- это же просто математика. Если у вас хотя бы один узел в РФ, то СОРМ не дремлет (при желании), а это значит, что можно составить граф коннектов и полей заголовков, а по большей плотности сразу видны «места наибольших коннектов», т.е. плотность трафика между 2-3-4-5 узлами значительно выше плотности остальных соединений, что приводит к абсолютной деанонимизации всей вашей сети.
Смотря какой узел. Если в под контролем СОРМ оказывается точка доступа, то вычислить можно только адрес расположения маршрутизатора и пользователей. Ничего больше.
А вообще, у нас была идея собрать систему защиты IT-ресурсов от киберразведки и направленных атак. Киберразведка — в понимании как деятельность, имеющая своей целью получение доступа, сбор и анализ определенной информации, в рамках которой, могут эксплуатироваться любые известные уязвимости, множественные ложные запросы, анализаторы трафика, ну и конечно социальная инженерия с административными ресурсами.
Так получается, что задача провалена чуть более, чем полностью, ведь анализатор трафика (тот же пассивный СОРМ, даже без DPI) дает полное и исчерпывающее понимание всей структуры вашей сети.
Не соглашусь. Во-первых, киберразведка это не только про СОРМ. Во-вторых, рассмотрим ситуацию:
1) Опубликованные (например, как в нашем эксперименте) релей-сервера — фронтенды располагаются вне РФ, пусть даже СОРМ собирает весь трафик между пользователями и точками входа.
2) Сервер-маршрутизатор расположен где-то.
3) Защищаемый сервер, давайте теоретически считать, в соответствии с ФЗ152 расположен где-то в РФ.
Как найти с чем сопоставлять данные СОРМ уходящие от пользователей в заграницу, ведь не известно где располагается защищаемый сервер? Значит надо мониторить все эксчендж интернет узлы, а это сами понимаете что за задача. Тем более, что данные уходящие за границу, возвращаются уже пережатые vpn. Нет тут даже предмета для математического исследования.
Кроме всего прочего, вы сильно заблуждаетесь в том, что мерами групповых политик и ограничения доступа пользователей к сокрытию информации (как вы писали в комменте ) что-то защищаете. Ведь сокрытие алгоритма, например, не делает алгоритм шифрования устойчивее, иногда даже наоборот (см. работы Шеннона и доказательства стойкости), у вас же средством обеспечения надежности является операционная система, НДВ которой, мягко говоря, не исследовано.
Абсолютно согласен, но это вне нашей задачи. Это вопрос к клиенту какой сервис и ОС использовать, впрочем, это всегда черный ящик, про который никто ничего не гарантирует.
Более правильным было бы создать «виртуальную» сеть, с серой адресацией, строилась бы которая на независимых маршрутизаторах, что вообще избавило бы от проблем настройки конечных пользовательских систем, забывчивости администраторов и, как вы писали, административного ресурса с применением социальной инженерии, т.е. для пользователя систему все выглядело бы как простая внутренняя локальная сеть; вы же, закрывая доступ, вызываете нездоровые вопросы и интерес.
Если вы про tor — согласен, возможно это и есть альтернатива. Но только надо понимать, что в этой схеме есть и минусы: система на самом деле централизованная, контролируется не вами, не гибкая в настройках (например, вы не можете выбрать маршрут), с точки зрения скорости работы — не гарантированная и не управляемая вами. Из нашего опыта, не все клиенты к этому готовы.
Если вы про tor — согласен, возможно это и есть альтернатива. Но только надо понимать, что в этой схеме есть и минусы: система на самом деле централизованная, контролируется не вами, не гибкая в настройках (например, вы не можете выбрать маршрут), с точки зрения скорости работы — не гарантированная и не управляемая вами. Из нашего опыта, не все клиенты к этому готовы.
Нет, я не про него. А о том, что терминаторами OpenVPN могут стать те же маленькие (и не очень) роутеры, а не сами сервера приложений. На самих же серверах приложений — просто сетевуха с адресом типа 172.16.0.0/n. Т.е. точка терминации смещается, соответственно клиенты, пользующиеся сервисом просто даже не предполагают, что это не их локальная сеть.
Ну и решается это:
Абсолютно согласен, но это вне нашей задачи. Это вопрос к клиенту какой сервис и ОС использовать, впрочем, это всегда черный ящик, про который никто ничего не гарантирует.
Согласен с abehterev. Немножко непонятно требование.
Задача ограничить доступ к физическим серверам или задача скрыть его нахождение?
Обе задачи решаются размщениев AWS или в Azure.
По защите от вражеских атак тот же Azure имеет кучу преимуществ по стравнению с самодельным решением, начиная от простейшего ServiceBus Relay, продолжая с гео-распределенной системой, размазанной по серверным центрам всего мира. На защите там задействованны спецы с громадным опытом, знаниями и ресурсами.
Но если к вам придут с предписанием суда на ваши данные, как вы обезопаситесь с помощью технических средств (см. недавнее дело Apple против US)?
Задача ограничить доступ к физическим серверам или задача скрыть его нахождение?
Обе задачи решаются размщениев AWS или в Azure.
По защите от вражеских атак тот же Azure имеет кучу преимуществ по стравнению с самодельным решением, начиная от простейшего ServiceBus Relay, продолжая с гео-распределенной системой, размазанной по серверным центрам всего мира. На защите там задействованны спецы с громадным опытом, знаниями и ресурсами.
Но если к вам придут с предписанием суда на ваши данные, как вы обезопаситесь с помощью технических средств (см. недавнее дело Apple против US)?
Задача ограничить доступ к физическим серверам или задача скрыть его нахождение?
Обе задачи решаются размщениев AWS или в Azure.
Не совсем с вами согласен по этим пунктам. По первому — да, но по второму — нет.
Как раз из вашей же цитаты:
Но если к вам придут с предписанием суда на ваши данные, как вы обезопаситесь с помощью технических средств (см. недавнее дело Apple против US)?
Т.е. вывести сервер из под юрисдикции получится, но станет известно его местоположение при первом же офиц. запросе. Вопрос сокрытия решается куда сложнее, немного развил тему здесь.
Ну про AWS и Azure тут еще можно поспорить. Задача ведь на самом деле — максимально затруднить вычисление местоположения серверов. Если сервер размещен в AWS или Azure — его вычислять не нужно и так понятно где он. Можно включать админресурс, социнжениринг, классический набор атак на облака. Релейные серверы можно брать в вышеуказанных местах, но не сам защищаемый сервер.
Ну да, тут не сокрытие местоположения сервера, а размазывание ресурсов по серверным центрам с разным географич. положением. Если еще вывести владельца ресурсов Azure/AWS в отдельную организацию, то получить данные даже по запросу органов будет очень проблематично.
Кстати, какие по вашему мнению лучшие методы физическо-юридической защиты? К примеру, данные на серверном центре в USA или Японии а клауд ресурсы арендуются через Гибралтарскую компанию. Управляет всем этим заопарком другая компания, с которой заключен договор, что они предоставляют секьюрити токены сторонним лицам только по запросу от органов своего государства, а хозяинам — только по особому протоколу, который не-знаю-как сразу прекращает выдачу в случаях…
Какой может быть потенциально возможный путь затребования данных для органов?
Кстати, какие по вашему мнению лучшие методы физическо-юридической защиты? К примеру, данные на серверном центре в USA или Японии а клауд ресурсы арендуются через Гибралтарскую компанию. Управляет всем этим заопарком другая компания, с которой заключен договор, что они предоставляют секьюрити токены сторонним лицам только по запросу от органов своего государства, а хозяинам — только по особому протоколу, который не-знаю-как сразу прекращает выдачу в случаях…
Какой может быть потенциально возможный путь затребования данных для органов?
Что касается физической защиты, Япония и США — это однозначно слабая скорость, что далеко не всем подходит, в европе-то найти что-то качественно работающее не всегда тривиальная задача. Что касается юридической защиты это очень индивидуальная история. Компаниям, которым нужно столь тщательное продумывание, правильно сначала проработать все свои модели угроз, затем выработать требования к скорости и отказоустойчивости и на основании этого, искать правильное решение.
Против лома нет приема. В ИБ задача всегда сводится к тому, чтобы сделать процесс взламывания более дорогим чем та ценность, которая будет получена в результате этого взлома.
Против лома нет приема. В ИБ задача всегда сводится к тому, чтобы сделать процесс взламывания более дорогим чем та ценность, которая будет получена в результате этого взлома.
NJ?
Третий сервер для входа — один из октетов — 255
Платить нужно нормальную зарплату администратору компании, тогда он не будет заинтересован в раскрытии секретов.
«Ваш К.О»
На практике вдруг админ перекупиться, конечно перекупиться только предложи, за такую то зп.
«Ваш К.О»
На практике вдруг админ перекупиться, конечно перекупиться только предложи, за такую то зп.
Сработает ли такое — zmap-ом пройтись по всему IPv4 и найти сервер, который отвечает на 80-м порту так же, как отвечают ваши точки доступа?
Идея хорошая, спасибо, буду помнить, что надо от нее закрываться. В данном экспериментально случае — сработало. На практике же, открытые сервисы будут с авторизацией и разнесены по точкам доступа по географическому и функциональному принципам, значит в боевых условиях zmap будет не эффективен.
Ну и IIS ваш красуется, несмотря на то, что внешне представляется nginx'ом и проксируется.
$ telnet 45.32.154.167 80
Trying 45.32.154.167…
Connected to 45.32.154.167.
Escape character is '^]'.
asdasdasd
]HTTP/1.1 400 Bad Request
Content-Type: text/html
Content-Length: 166
Connection: close
Server: Microsoft-IIS/8.0
175.15.236.151?
Самое главное так и не сказали — сценарий атаки.
Без оного могу из опыта: есть некий скрытый сервер. Вам шьётся дело с детской порнографией или содействие терроризму. В процессе обвинение требует доказательств путём экспертизы. В рамках экспертизы судья вправе истребовать доступ к телу.
Атака реализуется чисто юридически. И технические меры тут не спасут.
Без оного могу из опыта: есть некий скрытый сервер. Вам шьётся дело с детской порнографией или содействие терроризму. В процессе обвинение требует доказательств путём экспертизы. В рамках экспертизы судья вправе истребовать доступ к телу.
Атака реализуется чисто юридически. И технические меры тут не спасут.
Согласен, давайте подумаем вместе, вед интересно теоретически рассмотреть любые сценарии. Предположим, идет чисто юридическая атака, логика не совсем понятна, но допустим. Наверно правильным будет ответить на такую атаку: "к какому телу?" ведь пока нет адреса сервера, нет предмета для экспертизы.
В случае такой атаки запрос будет оформлен так, как нужно заинтересованной стороне. Например так: "Предоставить доступ к объектам хранения и обработки следующей информации: {{ тут список интересующей информации }}"
В таком случае IP сервера имеет чисто косметическое значение. Доступ будет запрошен к самой информации.
В разрезе нечестной конкуренции и шпионажа — это вполне себе решение.
В таком случае IP сервера имеет чисто косметическое значение. Доступ будет запрошен к самой информации.
В разрезе нечестной конкуренции и шпионажа — это вполне себе решение.
А если это не наш сервер? Вот, даже есть договор с фирмой «Рога и Копыта» на предоставление места. И телефончик, при звонке на который, вместе с ответом секретаря сервер нечаянно падает из стойки.
Я конечно извиняюсь, но когда это останавливало наши "компетентные органы". Реальность, к сожалению, такова, что если им что-то понадобится — Вы им это предоставите.
Вообще, я лично, считаю, что подобные меры могут быть эффективными только в качестве резервирования сервисов, как дешевое средство защиты от DDoS, инсайда, иных внутренних угроз. В общем для довольно узкого профиля. И, как размышлял автор, в качестве коммерческого сервиса/решения — это не самый удачный продукт, хотя бы иззатого, что спрос на такое решение будет довольно низким, я бы даже назвал это "штучным продуктом".
В остальном идея не нова. И свежий взгляд на старые проблемы — это интересно и полезно. Так и создаются технологии.
Вообще, я лично, считаю, что подобные меры могут быть эффективными только в качестве резервирования сервисов, как дешевое средство защиты от DDoS, инсайда, иных внутренних угроз. В общем для довольно узкого профиля. И, как размышлял автор, в качестве коммерческого сервиса/решения — это не самый удачный продукт, хотя бы иззатого, что спрос на такое решение будет довольно низким, я бы даже назвал это "штучным продуктом".
В остальном идея не нова. И свежий взгляд на старые проблемы — это интересно и полезно. Так и создаются технологии.
Автор почему-то не отвечал на мои письма. Тем не менее, сервер можно деанонимизировать при одном условии: если на него разрешены прямые подключения из интернета, что, судя по комментариям автора выше, является правдой.
При этом не обязательно, чтобы сервер отдал такую же страницу, или чтобы был доступен конкретно веб-сервер вообще: на сервере не отключены TCP Timestamps, а для проксирования запросов с точек доступа используется простое перенаправление портов (которое, к слову, осуществляется через OpenVPN-соединение со стандартными настройками шифрования, без tls auth, и по протоколу UDP).
Для определения аптайма нам нужен любой слушающий TCP-порт. Это может быть SSH-сервер, почтовый сервер, inetd, да что угодно. Просканировав весь интернет (а это делается в течение нескольких минут-часов на хорошем канале), можно найти сервер с точно таким же аптаймом, он и будет искомым сервером.
К сожалению, точки доступа на запросы отвечают очень неохотно, причина неясна. И это всего лишь статичная страница с одной картинкой. Если такой отклик будет у настоящей системы, то это использовать будет нельзя.
При этом не обязательно, чтобы сервер отдал такую же страницу, или чтобы был доступен конкретно веб-сервер вообще: на сервере не отключены TCP Timestamps, а для проксирования запросов с точек доступа используется простое перенаправление портов (которое, к слову, осуществляется через OpenVPN-соединение со стандартными настройками шифрования, без tls auth, и по протоколу UDP).
# ./p0f-client ../p0f-socket 151.236.15.175
First seen = 2016/03/05 22:21:10
Last update = 2016/03/05 22:21:10
Total flows = 1
Detected OS = Linux 3.x
HTTP software = ???
MTU = 1393
Network link = OpenVPN UDP bs128 SHA1
Language = ???
Distance = 7
Uptime = 23 days 20 hrs 25 min (modulo 49 days)Для определения аптайма нам нужен любой слушающий TCP-порт. Это может быть SSH-сервер, почтовый сервер, inetd, да что угодно. Просканировав весь интернет (а это делается в течение нескольких минут-часов на хорошем канале), можно найти сервер с точно таким же аптаймом, он и будет искомым сервером.
К сожалению, точки доступа на запросы отвечают очень неохотно, причина неясна. И это всего лишь статичная страница с одной картинкой. Если такой отклик будет у настоящей системы, то это использовать будет нельзя.
Чем поможет предложенная схема а борьбе с инсайдером или соц.инженерией?
Инсайдер имеет доступ к терминалам и информации, маловероятно что он собирался или должен был унести физический сервер.
Соц.инженерия совместно с вредоносным кодом даст контроль над терминалами, этого, как правило, достаточно для получения или вброса необходимой информации.
Инсайдер имеет доступ к терминалам и информации, маловероятно что он собирался или должен был унести физический сервер.
Соц.инженерия совместно с вредоносным кодом даст контроль над терминалами, этого, как правило, достаточно для получения или вброса необходимой информации.
Вспоминается случай, который был в одной организации несколько лет назад, я тогда там только начал работать. Пришла проверка из налоговой, закрыли магазин, попросили открыть все помещения/шкафы/сейфы. От одного шкафа "не нашли ключей" (сотрудники реально не знали что там стоит), его замок был взломан, внутри стоял сервер с монитором и клавамышой! На мониторе стандартное приглашение Windows 2000 для ввода логина/пароля (тут я начинаю медленно откладывать кирпичи). Налоговики на это посмотрели, в клаву потыкали, а потом последовал закономерный вопрос: "Кто знает пароль?". Когда "выяснилось" что пароля никто не знает, налоговики вернулись к бумажкам и на сервер забили. Занавес! :))
После этого конечно я настоял на перенос сервера и реализовал схему, похожую на озвученную в вашей статье. Жить стало спокойней.
P.S. Тут даже не проблема "сокрытия информации от властей" а то, что эти самые представители власти используются как инструмент давления конкурентами. Изъять всё оборудование и документацию для разбирательств по сфабрикованному делу, а через пол года "почти всё" вернуть — это вообще в порядке вещей и легко может сорвать или важную сделку или сезон активных продаж. А когда на рабочих местах мониторы по 200 баксов и RasPi в качестве тонких клиентов и маршрутизаторы на базе стоковых TP-link'ов с OpenWRT на борту — то хрен с ним, пусть конфискуют, можно в течении дня весь парк обновить и заново развернуть на новом железе.
После этого конечно я настоял на перенос сервера и реализовал схему, похожую на озвученную в вашей статье. Жить стало спокойней.
P.S. Тут даже не проблема "сокрытия информации от властей" а то, что эти самые представители власти используются как инструмент давления конкурентами. Изъять всё оборудование и документацию для разбирательств по сфабрикованному делу, а через пол года "почти всё" вернуть — это вообще в порядке вещей и легко может сорвать или важную сделку или сезон активных продаж. А когда на рабочих местах мониторы по 200 баксов и RasPi в качестве тонких клиентов и маршрутизаторы на базе стоковых TP-link'ов с OpenWRT на борту — то хрен с ним, пусть конфискуют, можно в течении дня весь парк обновить и заново развернуть на новом железе.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Прячем фактическое место, где стоит сервер компании: практические методы и вопрос