В первом случае это был строительный бизнес, у них одна из особенностей сферы в том, что на машинах не должно быть даже следов переписки, особенно перед тендерами. Поэтому у них RDP-ферма, а в офисе терминалы. Прятать надо было ядро. Во втором случае — сервисная компания, работающая с известными личностями (у них это просто слой безопасности, который они не считают лишним). В третьем — производство для нефтяной сферы, у которых по сфере нереальная недобросовестная конкуренция с забросом инсайдеров в чужие офисы.
Мы придумали вот такую схему:
В центре — ядро, вокруг ядра — релей-серверы периметра (дешёвые машины-прокси, на каждой — свой сервис), дальше — терминалы конечных пользователей. Покритикуйте, пожалуйста, ну или попробуйте вычислить IP сервера ядра на примере в конце.
Зачем это нужно?
Общая идея в том, чтобы только владелец бизнеса и главный админ знали, где серверы физически расположены. Дома у заказчика, в подвале офиса, в гараже или в дата-центре в Германии или Туле… — не важно.
Естественно, крупный бизнес умеет решать такие задачи (или они вообще не встают по ряду причин развитой ИБ). А вот малый и средний — нет, и даже силами админа не всегда удаётся это сделать более-менее правильно. Поэтому и стучали к нам.
Идея защиты в том, что:
— Сложно найти IP сервера, поскольку для этого придётся захватить одну из релей-машин и роутер.
— Релей-машины управляются сервером роутинга, который защищён традиционным набором: антиDDoS, QoS, активная система предотвращения вторжений и так далее.
— Сами по себе релеи настолько слабы по ресурсам, что любая попытка протащить через них DDoS закончится обрыванием связи с узлом и поднятием в течение 5–6 минут другой релей-машины где-либо по миру.
Релеи берутся из случайных дешёвых хостингов (в том числе уже проверенных нами) и поднимаются автоматически из дашборда сервера роутинга. Доступа до этого дашборда у нас нет — мы делаем инсталляцию и показываем, что менять. После этого заказчик устанавливает новый пароль и указывает IP головного сервера. Подтверждается это открытым кодом, который мы передаём заказчику.
Естественно, слабое звено — админ. Но если его перекупают или заставляют стучать, всё равно мало что поможет.
Точки отдают стандартные сервисы типа почты, внутреннего сайта, мессенджера, терминалок, приложений типа 1С. В общем, то же самое, что два классических сервера, замурованных в подвал, но вместо IP «подвальных» друзей за каменной кладкой в конфиге пользовательского терминала — IP машин периметра.
В итоге образуется ситуация, когда:
- Нельзя найти сервера ядра — то есть, например, нельзя украсть или забрать то, чего нет.
- Роутер-сервер защищает от стандартных угроз и фильтрует нецелевой трафик.
- У точки входа малая производительность — она ложится как плавкий предохранитель.
Подробнее:
Мы пока доделываем кластеризацию — раундробин и репликацию роутер-сервера. Точки доступа принципиально недублируемые, потому что это очень простая и дешёвая штуковина — проще развернуть новую, чем дублировать.
Детали:
• На чистой системе создаётся новый пользователь с sudo-привилегиями
• Отключается root.
• Устанавливаются OpenVPN, iptables-persistent, Prometheus, MongoDB, Nginx, скрипты управления, резервного копирования, мониторинга и т. п.
• Настраивается iptables.
• Настраивается Prometheus.
• Конфигурируются prometheus и node-exporter.
• Конфигурируются Nginx и MongoDB.
• Распаковываются и конфигурируются все скрипты, агенты и образы систем, которые будут задействованы на этапах инсталляции точек доступа и подключения защищаемых серверов.
От недобросовестной конкуренции — вполне себе защита. Вопрос в том, всё ли мы предусмотрели в своём велосипеде.
Ну и приглашаю попробовать проверить, где центральный сервер. Вот две машины с опубликованным на них web-приложением (в развёрнутом периметре есть ещё точки доступа):
45.32.154.167 — маршрут №1 к сайту.
151.236.15.175 — маршрут №2 к тому же самому сайту.
Если найдёте IP центрального сервера — с меня бутылка. Покажете, как именно нашли, — вторая. Контактная почта: binfini@yandex.ru
UPD 01.03.16 18:33 Кое-кто нашел третий маршрут к серверу, но не сам сервер.
UPD 01.03.16 21:38 Кое-кто еще нашел третий маршрут к серверу, но не сам сервер.
UPD 04.03.16 00:00 Спасибо всем большое за попытки и советы, кункурс приостанавливаю, адрес web-сервера найден не был.
Комментарии (90)
ollisso
01.03.2016 15:54+6Один из способов атаки — заставить "защищаемый сервер клиента" сообщить наружу свой айпи адрес любым способом. Зависит конечно от того, что пользователи могут делать на нём и какие задачи выполнять.
Например в первом случае, где РДП ферма. Если юзер откроет в РДП сессии браузер и оттуда зайдёт на адрес атакующего — как пойдёт трафик?
Если трафик пойдёт через центральный маршрутизатор, и нигде не будет указан айпи адрес фермы, то всё ок. Иначе — сами понимаете :)
Второй способ — почта :) Как идёт отправка почты (и вообще все подобные автоматические сервисы) с сервера-фермы? Если используется какой либо смтп сервер — то насколько хорошо он скрывает оригинальный айпи адрес? А то много чего можно найти в служебных заголовках.
binfini
01.03.2016 16:31Совершенно верно, тыкать в опубликованный сервис клиента — самый прямой способ обнаружить сервер. Поэтому всегда очень дотошно следует разбираться в сервисах клиента на предмет настроек безопасности.
Пользователям должны быть зарезаны права на просмотр служебной конфигурационной информации сервера, для RDP это IP и Mac адреса, ключи лицензий и т.п.
По архитектуре, трафик всех сервисов клиента всегда идет только в направлении сервера маршрутизации. То есть весь трафик RDP сессии всегда пройдет через роутер и какую-либо релей точку, IP которой и засветится.
Почта один из сложных сервисов, поэтому мы рекомендуем клиентам использовать браузерный доступ к внешней почте, который пробрасывается через отдельную релей точку доступа.
chemistmail
01.03.2016 16:05А чем LVS не подошел?
binfini
01.03.2016 16:37LVS мы тоже готовы использовать внутри периметра для распределения нагрузки между серверами, но не в качестве альтернативы самой системы безопасности. Архитектурно, LVS совмещает в себе функции и релей сервера и сервера маршрутизации и соответственно в нем отсутствует дополнительный уровень анонимности. Разница в том, что с нашего релей сервера нельзя узнать IP роутера, а с роутера нельзя узнать IP защищенных им серверов.
chemistmail
01.03.2016 17:00Вариант со спуфингом чем не анонимен?
binfini
01.03.2016 17:22Какой сценарий атаки предполагается?
chemistmail
01.03.2016 17:37Даже не представляю, ну вернее представляю, но от этих вариантов у вашей схемы тоже нет защиты, tor да, поможет и от таких вариантов. Просто вариант с lvs пилится на коленке за полчаса, ну отсюда и вопрос, чем вариант lvs + spoofing вас не устраивает, в чем он менее защищен?
binfini
01.03.2016 17:46Нам ведь нужно обеспечивать географическую распределенность между узлами… Так при чем тут спуффинг, мы же не в одной локальной сети… а если про L2 VPN… да, это возможно, но все равно нужна обертка, откидывающая IP адрес куда-то подальше, да и не каждый провайдер разрешит заниматься спуффингом. Что имеется в виду?
chemistmail
01.03.2016 17:56Вариант lvs-tun(вроде, проверять по документации лень), работал у меня в проде году так в 2005, скрывал файлохранилище на 100 терабайт, трафик около 4 — 5 гигабит, усредненный. Публичные точки были в штатах, европе. Где было ядро не актуально. В общем почитайте документацию lvs, там много забавного и интересного. По сути ваш кэйс покрывается этим по полностью. Без велосипедов. Есть ограничения, провайдер должен разрешать spoofing, но это решаемо.
binfini
01.03.2016 19:05Согласен, хорошая идея. Есть только вопрос, как быть с обеспечением IP-spoofing. Ведь при при тиражировании решения на большое количество клиентов, есть опасение однажды столкнуться с шквальными обрывами, что если какой-нить провайдер запретит такие подмены адресов. Не выглядит ли решение, когда пакеты в обратном направлении проходят через те же узлы немного стабильнее?
chemistmail
02.03.2016 08:56За пару лет, ни разу не столкнулся с такой проблемой. В общем нет такой проблемы.
RicoX
02.03.2016 08:59Я в своих сетях запрещаю на выход IP не входящие в анонсы маршрутизатора и очень многие делают именно так, это же прописано во всех рекомендациях, странно что не сталкивались, я регулярно натыкаюсь, когда заводишь к себе новую сеть, потом чтоб ускорить автоматику начинаешь пинать вышестоящих магистралов чтоб вручную протащили сеть через фильтры.
chemistmail
02.03.2016 23:17Очень многие, не означает все. Я думаю даже с вами можно договориться о такой услуге. Выставив вам страховку в виде договора о гарантии не заниматься плохими вещами, и финансовой компенсации за нарушение договора.
RicoX
03.03.2016 09:02Само собой, можно разрешить анонс любых сетей от определенного пира и протащить до L3, речь именно о дефолтной настройке, т.к. всякая зараза часто пользуется спуфингом для атак из ботнета.
amarao
01.03.2016 16:32+10Попытка изобрести доморощенный TOR.
Просто поднимите tor, засуньте виндовый сервер за socks-proxy tor'а — и всё, сервер сокрыт. Современных скоростей tor'а достаточно для всех практических нужд.
pwrlnd
01.03.2016 16:51Скорость там достаточная, но задержки большие — комфортной работы по RDP не будет
amarao
01.03.2016 16:54+1На устоявшемся соединении? Вполне терпимо. Вот рваться будет иногда — это да.
binfini
01.03.2016 17:03-1Стабильно: раз в 10 минут.
amarao
01.03.2016 18:17+3При этом рвётся нижележащий уровень, а для вышележащего туннеля это всего лишь лаг в работе.
binfini
02.03.2016 11:21Верно, а есть способ эти задержки снизить?
Какой технотренд на год-два вперед?amarao
02.03.2016 13:12Чисто теоретически, можно попробовать иметь два асинхронных соединения с быстрым failover'ом или даже дупликацией пересылаемых данных (кто быстрее — того и тапки).
Вообще, интересная тема для абстрактного CS проекта: как имея два или более tcp-соединения с неизвестными и неровными задержками получить сервис с меньшей latency.
Oxyd
01.03.2016 18:27Как мне кажется, этакую приватную onion сеть можно и на своей инфраструктуре поднять. На тех-же самых серверах "точек доступа". Поправьте если я не прав.
pwrlnd
01.03.2016 18:35Для этой задачи вполне подойдёт такой вариант. Но если же говорить про абсолютную анонимность (когда есть возможность "смотреть" трафик каждого узла), то точек нужно очень много, чтобы приватность была на уровне. А также масса пользователей этой сети, чтобы она была "наполнена" трафиком
binfini
01.03.2016 18:46Согласен, при малом количестве релей-серверов будет не достаточно луковично, а при большом — вне рамок задачи.
binfini
01.03.2016 17:03-1Работать со своим облачным сервером через общедоступные сервисы обеспечивающие анонимность — один из вариантов, теоретически максимально близких по уровню защищенности. Основных различия два:
1) Вы никогда не получите гарантированный, подконтрольный вам уровень скорости работы. Чем сложнее и надежнее публичная система, тем медленее и непредсказуемее она работает, а спрогнозировать ее производительность не представляется возможным.
2) Вы никогда не получите гарантированный и подконтрольный только клиенту уровень конфиденциальности, все публичный системы с определенной долей вероятности могут быть скомпромитированны.
А еще, TOR из практики наших клиентов все-таки тормозной, слишком часто для корп пользователей рвет соединения и сложный в настройке. А продолбать TOR соединение и выпустить трафик незавернутым в VPN — как нефиг делать. Ну и вопрос доверия: доверяешь ли ты миллионам пользователей TOR или хочешь иметь свою собственную распределенную сеть. В socks-proxy не всякое приложение засунешь, плюс известная проблема с UDP и костыли для ее решения. Например, SIP вообще в TOR не заведешь.amarao
01.03.2016 18:00+3В tor заворачиваются потоковые каналы. На бытовом уровне ssh и tor позволяют завернуть любой трафик (tun/tap туннель через ssh через tor), на промышленном уровне — openvpn@tcp через тот же tor. Network namespaces позволяют ограничить видимость сетевых интерфейсов и исключить любые утечки. Вы же винду виртуалкой на линуксовом сервере держите, правда?
Пользователям TOR'а доверять не нужно — не для этого он задумывался. Компрометация публичной системы (релея) ничего не ухудшит в работе TOR'а, если только не скомпрометированы все узлы из машрута.binfini
01.03.2016 18:55-1На самом деле, в нашем случае, это конечно не винда ;), ну да это не важно, сервис клиента может быть любым :).
Про архитектуру, верно, OpenVPN (ну или аналоги) через TOR вполне себе должны работать, есть только два сомнения:
1) Как быть с производительностью, клиентосы-то на практике не довольны, как тут быть?
2) На первый взгляд, если в процесс начнет встревать геополитика, TOR отрубать будут с большим усердием и для поддержки этого решения в стабильном состоянии понадобится больше компетенций и усилий админа, это для нас тоже открытый вопрос.
В действительности, хотим сделать что-то вроде коробки, которая не требует своего сильноразвитого и дорогого админа. Плюс всякие фишки с управлением в удобном дашборде.amarao
01.03.2016 18:59До момента бана тора должно пройти какое-то время. Переключение underlaying протокола для openvpn — не велика работа. В тривиальном виде — это любой канал до сервера зарубежом. Конечно, дойдёт очередь и до каналов до серверов зарубежом, и до выездных виз. Но — всему своя очередь. Пока что можно резвиться таким образом.
binfini
02.03.2016 11:22В тривиальном случае с каналом до зарубежа — видится некоторая уязвимость в том, что очевидно где сам сервер, делай с ним чего хочешь: ковыряй, собирай данные, ддось. Тут-то и возникла идея сделать решение непрозрачным, распределенным. Идея сама по себе здоровая?
amarao
02.03.2016 13:15-1Ну, это tor и есть. А за жопку брать будут не отслеживая ip'шники и трекая сервера в разных странах, а по финансовым операциям.
Для совершенного уровня надо использовать bitcoin через tor, да ещё серьёзно задуматься о методе ввода средств, т.к. все операции в bitcoin хорошо видны в блокчейне. Миксеры, биржи и всё такое. И одноразовые кошельки для оплаты.
Disen
01.03.2016 18:11+3Как тут верно заметили ранее — самый действенный способ используя что-то типа Server-Side-Request-Forgery (SSRF) заставить сервер постучаться куда надо, тем самым деанонимизировав себя.
Другой интересный вопрос, как заставить виндовый сервер на IIS8, отдающий бездушный статический html без кнопочек и формочек, сделать это :)vgray
01.03.2016 20:25+2Решал задачку, похожую на задачку автора. Делал точку входа на сервере на 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 адреса клиентаbinfini
02.03.2016 11:25Да, мы тоже по сути эту схему в начале делали с точками "входа", потом поняли, что некоторые виды трафика по условиям задачи нужно отдавать через другие точки "выхода". Типа в сторону gmail трафик один с одного адреса, в сторону сбербанка с другого. Но потом когда задумались о тиражируемой коробке, переработали схему. теперь у нас универсальные "точки доступа" они могут смотреть как в сторону клиента, так и в сторону сервиса.
Отдельная история с NAT когда SIP через него пытаешься гнать, тут мы тоже неслабое число граблей собрали. Но по факту, получили не просто криптофон, а анонимный криптофон, при звонке или чате с которого нельзя, прослушивая трафик, установить даже кому ты звонил или писал.
Еще мы поняли, что чтобы клиенту нужно отдавать сервис без нашего к нему доступа, то есть клиенту отдается коробка, к которой у нас нет ни доступа, но и даже информации о том на каких адресах она работает. Тут пришлось пилить систему управления, легкую и удобную.
Oxyd
02.03.2016 00:05+3Но при этом, конкретно этот сервер, с незакрытой уязвимостью MS15-034
RicoX
02.03.2016 08:52Тоже нашел эту дырку, но т.к. на фронте nginx, то она не отрабатывает. Сразу попробовал эксплуатировать и вывести ipconfig, но получил обычную 416, так что не критично.
xtreme
02.03.2016 09:49Там перекомпиленный nginx, который в ident отдает "Microsoft-IIS/8.0". Понять можно по 404-й странице, когда страница генерится nginx-ом.
RicoX
02.03.2016 09:50Не факт, либо так либо на фронте nginx с кешированием и ошибками, на бэке действительно Microsoft-IIS/8.0, тут понять сложно так как доступна только статичная страничка с одной картинкой.
xtreme
02.03.2016 10:05Могу ошибаться (а проверять на практике сейчас лениво), но кажется мне, что стандартная 404-я страница nginx говорит про "proxy_intercept_errors on;", а значит страница генерится nginx-ом, но в "Server" указан Microsoft-IIS/8.0, хотя в этом случае должен быть nginx.
Пойду в подтверждение исходники посмотрю, что-ли...
BalinTomsk
01.03.2016 18:16-1---сделать так, чтобы никто не узнал, где именно стоят сервера компании
А разве паяльник не решает такие случаи?
Гораздо проще снять смежное помещение на другую организацию, протянуть туда оптоволокно и работать. Если что, в стояках они долго будут кабель искать, за это время все можно уничтожить.
Если клиенты богатые можно запустить спутник с сервером. Перехватить спутник физически может тока мини-шатл в США.Oxyd
01.03.2016 18:42+1Как вы за оптоволокном скроете IP адреса? И да, тогда уж проще парочку каких-нибудь дальнобойных микротиков, и сервер подальше.
Но опять таки, это немного не тот кейс. У вас скорее кейс для скрытия от контролирующих органов(где рубильник вырубил и всё), здесь-же защита от конкурентов.BalinTomsk
01.03.2016 19:42----Как вы за оптоволокном скроете IP адреса?
В названии статьи: Прячем фактическое место, где стоит сервер компании
По волокну ваш сервер стоит за натом в внутренними IP адресами, через vpn ip уносится в любую точку мира. В итоге не ip ни lat/lon непосвяшенным не известны.Oxyd
01.03.2016 19:54-2Название статьи немного многозначительное, простите мой каламбур, но всё-же применение несколько другое, чем описанное в вашем предыдущем комменте. А вот дискредитация внутренней сети, даже за NAT-ом, вещь довольно распространённая. Так что архитектура описанная в статье несколько более защищена от таких атак.
abehterev
01.03.2016 19:19+1У меня вопрос — от кого защищаетесь?
В вашем случае — все каналы строятся через интернет, что значит — все соединения проходят СОРМ, что значит — если вы реально "кому-то" интересны, то построить граф Макрова или выполнить частотное сравнение полей пакетов (автоматически) не представляет никакой сложности. Т.е. поскольку ваши точки общаются значительно чаще, чем одна из точек и внешний мир, адрес каждой из них не представляет секрета. TOR, кстати, уязвим по этой же причине, при недостаточности энтропии — т.е. большого числа случайных соединений между узлами.
Другими словами хочу сказать следующее: если задача была обезопасить трафик и вынести данные в "условно-безопасную" юрисдикцию, то задача почти решена (никто не отменял паяльник, как писали выше), если же задача была скрыть нахождение сервера (тем более у кого-то дома), то не только вводите себя и клиента в заблуждение, но может и подставляете кого-то физически.binfini
01.03.2016 21:17Метод по Маркову — скорее всего малореален, ведь с одной стороны мы предполагаем, что клиенты чаще будут использовать серверы, размещенные вне пределов РФ, не нарушая при этом никаких ФЗ, а СОРМ будет эффективен в случае, если большая часть инфраструктуры находится на территории РФ. Да и если паяльник пойдет в ход, никакие сложные математические методы не понядобятся.
А вообще, у нас была идея собрать систему защиты IT-ресурсов от киберразведки и направленных атак. Киберразведка — в понимании как деятельность, имеющая своей целью получение доступа, сбор и анализ определенной информации, в рамках которой, могут эксплуатироваться любые известные уязвимости, множественные ложные запросы, анализаторы трафика, ну и конечно социальная инженерия с административными ресурсами.
Как видится, одним из факторов, существенно усложняющим киберразведку является невычисляемость адреса расположения сервера, так как в этом случае, сужаются возможности социально-инженерных и административных приемов.abehterev
02.03.2016 10:50Метод по Маркову — скорее всего малореален, ведь с одной стороны мы предполагаем, что клиенты чаще будут использовать серверы, размещенные вне пределов РФ, не нарушая при этом никаких ФЗ, а СОРМ будет эффективен в случае, если большая часть инфраструктуры находится на территории РФ.
Как связан метод, с местоположением серверов,- это же просто математика. Если у вас хотя бы один узел в РФ, то СОРМ не дремлет (при желании), а это значит, что можно составить граф коннектов и полей заголовков, а по большей плотности сразу видны "места наибольших коннектов", т.е. плотность трафика между 2-3-4-5 узлами значительно выше плотности остальных соединений, что приводит к абсолютной деанонимизации всей вашей сети.
А вообще, у нас была идея собрать систему защиты IT-ресурсов от киберразведки и направленных атак. Киберразведка — в понимании как деятельность, имеющая своей целью получение доступа, сбор и анализ определенной информации, в рамках которой, могут эксплуатироваться любые известные уязвимости, множественные ложные запросы, анализаторы трафика, ну и конечно социальная инженерия с административными ресурсами.
Так получается, что задача провалена чуть более, чем полностью, ведь анализатор трафика (тот же пассивный СОРМ, даже без DPI) дает полное и исчерпывающее понимание всей структуры вашей сети.
Как видится, одним из факторов, существенно усложняющим киберразведку является невычисляемость адреса расположения сервера, так как в этом случае, сужаются возможности социально-инженерных и административных приемов.
см. доводы выше. Кроме всего прочего, вы сильно заблуждаетесь в том, что мерами групповых политик и ограничения доступа пользователей к сокрытию информации (как вы писали в комменте ) что-то защищаете. Ведь сокрытие алгоритма, например, не делает алгоритм шифрования устойчивее, иногда даже наоборот (см. работы Шеннона и доказательства стойкости), у вас же средством обеспечения надежности является операционная система, НДВ которой, мягко говоря, не исследовано.
Более правильным было бы создать "виртуальную" сеть, с серой адресацией, строилась бы которая на независимых маршрутизаторах, что вообще избавило бы от проблем настройки конечных пользовательских систем, забывчивости администраторов и, как вы писали, административного ресурса с применением социальной инженерии, т.е. для пользователя систему все выглядело бы как простая внутренняя локальная сеть; вы же, закрывая доступ, вызываете нездоровые вопросы и интерес.binfini
02.03.2016 14:02-1Как связан метод, с местоположением серверов,- это же просто математика. Если у вас хотя бы один узел в РФ, то СОРМ не дремлет (при желании), а это значит, что можно составить граф коннектов и полей заголовков, а по большей плотности сразу видны «места наибольших коннектов», т.е. плотность трафика между 2-3-4-5 узлами значительно выше плотности остальных соединений, что приводит к абсолютной деанонимизации всей вашей сети.
Смотря какой узел. Если в под контролем СОРМ оказывается точка доступа, то вычислить можно только адрес расположения маршрутизатора и пользователей. Ничего больше.
А вообще, у нас была идея собрать систему защиты IT-ресурсов от киберразведки и направленных атак. Киберразведка — в понимании как деятельность, имеющая своей целью получение доступа, сбор и анализ определенной информации, в рамках которой, могут эксплуатироваться любые известные уязвимости, множественные ложные запросы, анализаторы трафика, ну и конечно социальная инженерия с административными ресурсами.
Так получается, что задача провалена чуть более, чем полностью, ведь анализатор трафика (тот же пассивный СОРМ, даже без DPI) дает полное и исчерпывающее понимание всей структуры вашей сети.
Не соглашусь. Во-первых, киберразведка это не только про СОРМ. Во-вторых, рассмотрим ситуацию:
1) Опубликованные (например, как в нашем эксперименте) релей-сервера — фронтенды располагаются вне РФ, пусть даже СОРМ собирает весь трафик между пользователями и точками входа.
2) Сервер-маршрутизатор расположен где-то.
3) Защищаемый сервер, давайте теоретически считать, в соответствии с ФЗ152 расположен где-то в РФ.
Как найти с чем сопоставлять данные СОРМ уходящие от пользователей в заграницу, ведь не известно где располагается защищаемый сервер? Значит надо мониторить все эксчендж интернет узлы, а это сами понимаете что за задача. Тем более, что данные уходящие за границу, возвращаются уже пережатые vpn. Нет тут даже предмета для математического исследования.
Кроме всего прочего, вы сильно заблуждаетесь в том, что мерами групповых политик и ограничения доступа пользователей к сокрытию информации (как вы писали в комменте ) что-то защищаете. Ведь сокрытие алгоритма, например, не делает алгоритм шифрования устойчивее, иногда даже наоборот (см. работы Шеннона и доказательства стойкости), у вас же средством обеспечения надежности является операционная система, НДВ которой, мягко говоря, не исследовано.
Абсолютно согласен, но это вне нашей задачи. Это вопрос к клиенту какой сервис и ОС использовать, впрочем, это всегда черный ящик, про который никто ничего не гарантирует.
Более правильным было бы создать «виртуальную» сеть, с серой адресацией, строилась бы которая на независимых маршрутизаторах, что вообще избавило бы от проблем настройки конечных пользовательских систем, забывчивости администраторов и, как вы писали, административного ресурса с применением социальной инженерии, т.е. для пользователя систему все выглядело бы как простая внутренняя локальная сеть; вы же, закрывая доступ, вызываете нездоровые вопросы и интерес.
Если вы про tor — согласен, возможно это и есть альтернатива. Но только надо понимать, что в этой схеме есть и минусы: система на самом деле централизованная, контролируется не вами, не гибкая в настройках (например, вы не можете выбрать маршрут), с точки зрения скорости работы — не гарантированная и не управляемая вами. Из нашего опыта, не все клиенты к этому готовы.abehterev
02.03.2016 15:40Если вы про tor — согласен, возможно это и есть альтернатива. Но только надо понимать, что в этой схеме есть и минусы: система на самом деле централизованная, контролируется не вами, не гибкая в настройках (например, вы не можете выбрать маршрут), с точки зрения скорости работы — не гарантированная и не управляемая вами. Из нашего опыта, не все клиенты к этому готовы.
Нет, я не про него. А о том, что терминаторами OpenVPN могут стать те же маленькие (и не очень) роутеры, а не сами сервера приложений. На самих же серверах приложений — просто сетевуха с адресом типа 172.16.0.0/n. Т.е. точка терминации смещается, соответственно клиенты, пользующиеся сервисом просто даже не предполагают, что это не их локальная сеть.
Ну и решается это:
Абсолютно согласен, но это вне нашей задачи. Это вопрос к клиенту какой сервис и ОС использовать, впрочем, это всегда черный ящик, про который никто ничего не гарантирует.
Leo_Gan
01.03.2016 22:01+2Согласен с abehterev. Немножко непонятно требование.
Задача ограничить доступ к физическим серверам или задача скрыть его нахождение?
Обе задачи решаются размщениев AWS или в Azure.
По защите от вражеских атак тот же Azure имеет кучу преимуществ по стравнению с самодельным решением, начиная от простейшего ServiceBus Relay, продолжая с гео-распределенной системой, размазанной по серверным центрам всего мира. На защите там задействованны спецы с громадным опытом, знаниями и ресурсами.
Но если к вам придут с предписанием суда на ваши данные, как вы обезопаситесь с помощью технических средств (см. недавнее дело Apple против US)?abehterev
02.03.2016 10:54Задача ограничить доступ к физическим серверам или задача скрыть его нахождение?
Обе задачи решаются размщениев AWS или в Azure.
Не совсем с вами согласен по этим пунктам. По первому — да, но по второму — нет.
Как раз из вашей же цитаты:
Но если к вам придут с предписанием суда на ваши данные, как вы обезопаситесь с помощью технических средств (см. недавнее дело Apple против US)?
Т.е. вывести сервер из под юрисдикции получится, но станет известно его местоположение при первом же офиц. запросе. Вопрос сокрытия решается куда сложнее, немного развил тему здесь.
binfini
02.03.2016 11:20Ну про AWS и Azure тут еще можно поспорить. Задача ведь на самом деле — максимально затруднить вычисление местоположения серверов. Если сервер размещен в AWS или Azure — его вычислять не нужно и так понятно где он. Можно включать админресурс, социнжениринг, классический набор атак на облака. Релейные серверы можно брать в вышеуказанных местах, но не сам защищаемый сервер.
Leo_Gan
02.03.2016 19:52Ну да, тут не сокрытие местоположения сервера, а размазывание ресурсов по серверным центрам с разным географич. положением. Если еще вывести владельца ресурсов Azure/AWS в отдельную организацию, то получить данные даже по запросу органов будет очень проблематично.
Кстати, какие по вашему мнению лучшие методы физическо-юридической защиты? К примеру, данные на серверном центре в USA или Японии а клауд ресурсы арендуются через Гибралтарскую компанию. Управляет всем этим заопарком другая компания, с которой заключен договор, что они предоставляют секьюрити токены сторонним лицам только по запросу от органов своего государства, а хозяинам — только по особому протоколу, который не-знаю-как сразу прекращает выдачу в случаях…
Какой может быть потенциально возможный путь затребования данных для органов?binfini
04.03.2016 02:05Что касается физической защиты, Япония и США — это однозначно слабая скорость, что далеко не всем подходит, в европе-то найти что-то качественно работающее не всегда тривиальная задача. Что касается юридической защиты это очень индивидуальная история. Компаниям, которым нужно столь тщательное продумывание, правильно сначала проработать все свои модели угроз, затем выработать требования к скорости и отказоустойчивости и на основании этого, искать правильное решение.
Против лома нет приема. В ИБ задача всегда сводится к тому, чтобы сделать процесс взламывания более дорогим чем та ценность, которая будет получена в результате этого взлома.
PerlPower
01.03.2016 22:05А на чем реализован сервер маршрутизации? Набор правил IPtables? Модифицированный iptables? Или какой-то свой маршрутизатор?
У вас кажется "точки" используются в двух разных смыслах: как точки доступа и как:
Точки отдают стандартные сервисы типа почты, внутреннего сайта, мессенджера, терминалок, приложений типа 1С
binfini
01.03.2016 22:19Обычный Iptables.
Точки, они же релей сервера, являются узлами подключения пользователей к сервисам. Они с одной стороны, точки доступа пользователей к защищенному серверу, а с другой стороны отдают "стандартные сервисы". Сегодня, в качестве сервиса опубликован web сайт.
Xanter
01.03.2016 22:36-6Платить нужно нормальную зарплату администратору компании, тогда он не будет заинтересован в раскрытии секретов.
«Ваш К.О»
На практике вдруг админ перекупиться, конечно перекупиться только предложи, за такую то зп.
mwizard
02.03.2016 02:14+1Сработает ли такое — zmap-ом пройтись по всему IPv4 и найти сервер, который отвечает на 80-м порту так же, как отвечают ваши точки доступа?
kafeman
02.03.2016 02:36Тоже первой в голову пришла такая мысль. И судя по тому, что нашли еще один фронт — не нам одним :-)
Но увы, судя по картинке, там все идет через VPN. Во внешний мир 80-ый порт закрыт.binfini
02.03.2016 11:27Внутри все по vpn, верно, а наружу в этом кейсе у нас все по 80-му порту идет в открытую.
binfini
02.03.2016 11:17Идея хорошая, спасибо, буду помнить, что надо от нее закрываться. В данном экспериментально случае — сработало. На практике же, открытые сервисы будут с авторизацией и разнесены по точкам доступа по географическому и функциональному принципам, значит в боевых условиях zmap будет не эффективен.
abehterev
02.03.2016 11:27Ну и 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
SLIDERWEB
03.03.2016 21:49Самое главное так и не сказали — сценарий атаки.
Без оного могу из опыта: есть некий скрытый сервер. Вам шьётся дело с детской порнографией или содействие терроризму. В процессе обвинение требует доказательств путём экспертизы. В рамках экспертизы судья вправе истребовать доступ к телу.
Атака реализуется чисто юридически. И технические меры тут не спасут.binfini
04.03.2016 01:50Согласен, давайте подумаем вместе, вед интересно теоретически рассмотреть любые сценарии. Предположим, идет чисто юридическая атака, логика не совсем понятна, но допустим. Наверно правильным будет ответить на такую атаку: "к какому телу?" ведь пока нет адреса сервера, нет предмета для экспертизы.
SLIDERWEB
04.03.2016 05:14В случае такой атаки запрос будет оформлен так, как нужно заинтересованной стороне. Например так: "Предоставить доступ к объектам хранения и обработки следующей информации: {{ тут список интересующей информации }}"
В таком случае IP сервера имеет чисто косметическое значение. Доступ будет запрошен к самой информации.
В разрезе нечестной конкуренции и шпионажа — это вполне себе решение.
SunX
04.03.2016 13:33+1А если это не наш сервер? Вот, даже есть договор с фирмой «Рога и Копыта» на предоставление места. И телефончик, при звонке на который, вместе с ответом секретаря сервер нечаянно падает из стойки.
SLIDERWEB
05.03.2016 01:44Я конечно извиняюсь, но когда это останавливало наши "компетентные органы". Реальность, к сожалению, такова, что если им что-то понадобится — Вы им это предоставите.
Вообще, я лично, считаю, что подобные меры могут быть эффективными только в качестве резервирования сервисов, как дешевое средство защиты от DDoS, инсайда, иных внутренних угроз. В общем для довольно узкого профиля. И, как размышлял автор, в качестве коммерческого сервиса/решения — это не самый удачный продукт, хотя бы иззатого, что спрос на такое решение будет довольно низким, я бы даже назвал это "штучным продуктом".
В остальном идея не нова. И свежий взгляд на старые проблемы — это интересно и полезно. Так и создаются технологии.
ValdikSS
05.03.2016 22:30+1Автор почему-то не отвечал на мои письма. Тем не менее, сервер можно деанонимизировать при одном условии: если на него разрешены прямые подключения из интернета, что, судя по комментариям автора выше, является правдой.
При этом не обязательно, чтобы сервер отдал такую же страницу, или чтобы был доступен конкретно веб-сервер вообще: на сервере не отключены 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, да что угодно. Просканировав весь интернет (а это делается в течение нескольких минут-часов на хорошем канале), можно найти сервер с точно таким же аптаймом, он и будет искомым сервером.
К сожалению, точки доступа на запросы отвечают очень неохотно, причина неясна. И это всего лишь статичная страница с одной картинкой. Если такой отклик будет у настоящей системы, то это использовать будет нельзя.
nvv
06.03.2016 14:47Чем поможет предложенная схема а борьбе с инсайдером или соц.инженерией?
Инсайдер имеет доступ к терминалам и информации, маловероятно что он собирался или должен был унести физический сервер.
Соц.инженерия совместно с вредоносным кодом даст контроль над терминалами, этого, как правило, достаточно для получения или вброса необходимой информации.
Drag13
Бутылка за поиск бреши в решении для корпоративных клиентов с особо чувствительной информацией? Это случайно не бутылка текилы Spluch?
binfini
На данном этапе хочется понять, правильная ли идея с архитектурой. Естественно, когда это станет продуктом (если станет), я поставлю и хорошие bug bounty. Не уровня Facebook, но хорошие.
mx2000
Зависит от специфики софта на сервере. Например, если у юзера есть возможность вынудить сервер сделать запрос во внешний мир — будет видно откуда пришел запрос. Например, при создании превью картинки по сторонней ссылке.
nckma
security by obscurity