DeepTech-группа работает над созданием технической базы сопротивления тотальному слежению и контролю.

Слежение и контроль за гражданами непрерывно усиливается во всём мире, переходя все разумные границы. Мы предлагаем всем неравнодушным техническим специалистам объединиться для защиты.

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

Одна из простых идей: для выхода из-под контроля полезно использовать собственные self-hosted сервисы. Поэтому кроме предоставления сервисов, мы развиваем их так, чтобы достаточно просто можно было поднять их у себя.

Подробнее можно прочитать на нашем сайте

• в интернете: http://deeptechgroup.net
• в сети Тор http://deeptehvdjx3xbek.onion

Итоги сделанного за год

Сервисы (в основном как скрытые сервисы в Торе)

• Запущен форум (с подправленным движком для сокрытия метаданных)
• Опубликован статический сайт в Интернете и как скрытый сервис в Торе
• Поднят свой git-хостинг на основе gitolite и cgit
• Поднят trac в качестве трекера задач и вики

Разработка

• Начата работа над проектом Delaytor

О проекте Delaytor: для защиты от атак шейпинга и пересечения предлагается внести существенные задержки между отправкой сообщения и его доставкой. Первая версия реализуется в виде self-hosted сервиса, который принимает сообщения и потом с задержкой в несколько часов отправляет их на целевые сайты/платформы (в соцсети, блоги, форумы, мессенджеры).

Из недостигнутого

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

Планы на будущий год

• Выпустить Delaytor v1.0 с поддержкой нескольких целевых сайтов
• Улучшить инфраструктуру (автоматические бакапы, мониторинг, обновления)
• Завершить исследование атак шейпинга и пересечения (выполнить необходимые расчёты и симуляции)
• Создать небольшое сообщество

Последний пункт наиболее сложный для нас, будем рады предложениям, как правильно работать над этим в наших условиях.

Источник: https://deeptechgroup.net/blog/dtg-public-one-year/

Обсудить на форуме DTG: http://dtforceyo5xwxfl7.onion/forumdisplay.php?fid=2

Всем привет!

Мы разрабатываем новое open-source веб-приложение с нуля, называется Delaytor (http://dtdevgo7fei5dy6ljfrahl5j5pjq5zo7rlhpl3myetexpxv56upinuad.onion/dtg-delaytor.git/about/ - хостимся у себя в Торе).

Задача: предоставить возможность пользоваться системами коммуникации (соцсети, блоги, мессенджеры, форумы) автоматизированно.

Для чего нужно: прямое использование анонимных сетей типа Тор или I2P уязвимо к атакам пересечения и шейпинга траффика (см. например https://deeptechgroup.net/blog/practical-attacks-against-realtime-anonymizing-systems/). Наиболее эффективная защита от подобных атак – уйти от доступа к сайтам в реальном времени, внеся существенную задержку между отправкой сообщения в сеть и получением этого сообщения целевой платформой (и в другую сторону, задержку между отправкой и получением ответа).

Кому нужно: блоггерам для публикаций своих постов сразу на нескольких ресурсах; а также всем, кому не безразлична ситуация с тотальным слежением и контролем (а шапочка из фольги уже не справляется), а также бойцам информационного сопротивления.

Чем отличается от уже существующих систем автопостинга:

• self-hosted
• открытое и свободное ПО
• фокус на псевдонимности и безопасности пользователей
• пытается покрыть весь процесс работы с целевым сайтом или сервисом так, чтобы пользователю не требовалось заходить на этот ресурс без Delaytor’а, таким образом снижая риск деанонимизации
• не предназначен для рассылки спама

Архитектура решения

Была предложена такая архитектура (по ссылке схема в png).

На своей VPS пользователь запускает веб-приложение Delaytor как скрытый сервис Тор или I2P, затем управляет им через браузер. Указывает настройки (параметры доступа к целевым сайтам и мессенджерам). Передает сообщение, которое нужно отправить; указывает, куда. Указывает, через какие прокси или VPN нужно его доставить. После этого отключается, и Delaytor через заданное время осуществляет отправку (также может осуществить чтение ответов, комментариев и т.д. и т.п.). Отправка выполняется конкретным сервер-сайд клиентом под каждый конкретный сайт или сервис. Например, для отправки в Телеграм можем использовать официальную библиотеку. Для отправки на LOR - браузерный клиент. Для отправки в Твиттер - официальный REST API соцсети. И т.д. Компоненты веб-приложения:

Core, User API

• Python, Django
• шедулинг автопостинга, управление…
• поддержка нескольких пользователей (для групп)
• админский интерфейс

База данных

• MongoDB или Postgres?

Клиент

• веб-клиент без Javascript (требование безопасности и правила хорошего тона, принятые в Торе)
• Другие (десктопный, мобильный)

Модуль конфигурации

• три уровня конфигов: кампании, пользователя и всего сервера (админские)
• сохранение параметров доступа к целевым сайтам
• сохранение параметров доступа к внешим сервисам и АПИ (решение капч, VPN, прокси)

Модули Workers

• абстрактные интерфейсы типа Блог, Мессенджер, Форум, которые реализуются в воркерах
• запускаются как отдельные приложения с REST-интерфейсом в докер-контейнерах - для упрощения маршрутизации траффика и для изоляции (нужно ли?)
• могут быть написаны на любом языке (для реализаций с использованием нативных библиотек мессенджеров, типа Телеграма, зависит от наличия биндингов на этом языке)
• модуль HTTP API worker может быть один для всех сервисов, предоставляющих такой API (возникнет вопрос с маршрутизацией траффика…)
• браузерные модули могут использовать Splash, Selenium и другие технологии (TBD)
• мы хотим использовать HTTP API везде где только можно, но не все сайты его предоставляют, или же предоставляют очень урезанные API. В некоторых случаях мы можем использовать внутренние API, используемые мобильными приложениями этих систем вместо использования браузера.

Модуль обхода CAPTCHA

• мы бы хотели вообще не попадать на капчи, но это вряд ли возможно на практике
• многие капчи можно распознать используя современное машинное обучение и OCR. Есть облачные сервисы для этого, или же мы можем попробовать сделать свой (явно не в версии v1)
• человеческие фермы для решения капч, хотя и уродливы, но предоставляют дешевый сервис (учитывая, что мы не предполагаем спамить), а также доступ через API. Так что по-видимому разумно их использовать…

Транспортный модуль

• поддерживает Tor, I2P, VPN, сети прокси-серверов
• позволяет комбинировать транспорты, например Тор + прокси или Тор + VPN
• маршрутизирует траффик в соответствии с конфигурацией (т.е. различные целевые сайты могут получать данные по разным путям)

Вопросы

0. Мы будем рады конструктивной критике нашего подхода. Конкретные вопросы, которые пока не продуманы в архитектуре решения, ниже.

1. Стоит ли использовать докер-контейнеры для воркеров? Конечно, решение self-hosted, большой нагрузки не предполагается, но всё же. Польза в них видится в том, что там уже реализована виртуальная сеть, соответственно можно инстанциировать контейнеры с нужной конфигурацией сетей для маршрутизации траффика через сконфигурированный транспорт.

2. Если докер не использовать, то как тогда можно решить задачу маршрутизации? Грубо говоря, хотим один HTTP-запрос отправить через Tor + VPN к сайту A, а второй - через Tor + прокси к сайту Б.

3. Какая база данных лучше подойдет для данного проекта? Видятся два варианта - Postgres или MongoDB. Пока склоняемся к Монге, потому что будем хранить разнородные данные (посты, комменты, соообщения) из разных форумов, соцсетей, мессенджеров. Кажется, реляционная база принесет больше сложностей в разработке… При этом аналитика нормализованных данных не очень интересна в данном приложении (не первостепенна).

4. Какие браузерные (и небраузерные, когда это возможно) технологии автоматизации вы порекомендуете? Конкретно, для таких классов задач:

   • автоматизация простых блогов, форумов (типа LOR, phpBB и др.)
   • автоматизация джаваскриптовых соцсетей (типа VK, FB)

Спасибо!

Всем привет.

Deep Tech Group уже появлялась на ЛОРе раньше, но для тех кто пропустил момент, подробнее о нашей инициативе можно прочитать на https://deeptechgroup.net или в Торе http://deeptehvdjx3xbek.onion

Наша группа развивается, и недавно мы опубликовали свой self-hosted git-сервис: https://deeptechgroup.net/blog/git-service-published/

Возникают такие широкие вопросы и задачи

1. Код сервисов опубликован (http://dtdevgo7fei5dy6ljfrahl5j5pjq5zo7rlhpl3myetexpxv56upinuad.onion/dtg-ser...). Но что можно улучшить в нашем подходе? Какие best practices мы не применяем тут, а стоит?

2. Как повысить реюзабилити. Проблемы тут такие: сервисы очень тесно завязаны друг на друга, не так-то просто исключить один из них или добавить новый - нужно в нескольких местах редактировать всё это. Фактически, docker-compose какой-то монолитный получается. разрезать его на отдельные yml - тоже сомнительно. Как на счёт docker app? https://github.com/docker/app Годная вещь, стоит пробовать?

3. Нужно интегрировать i2p параллельно с Тором, пока некому заняться.

4. Дальнейшее развитие инфраструктуры. Вот мы добавим trac, и по фичам всё будет готово. Но внутри много проблем остается:

• бакапы. Как бакапить всё это правильно.
• обновления софта в контейнерах и на хостах

5. На будущее возможно пригодится

• масштабирование
• свой репозиторий с контейнерами (сейчас собираются прямо на проде)
• оркестрация
• ...

Если вам интересно заниматься подобными вещами - присоединяйтесь!

Всем привет,

Имеется некий веб-сервис, который обычно работает на одном домене. Например, форум. Или вики. Или что-либо ещё. Логин обычно привязывается к кукам, которые тоже привязаны к домену. Необходимо сделать так, чтобы сервис стал доступен с нескольких разных доменов. Без редиректа.

Для пояснения:

example.com   ->  
example.onion ->  | same service |
another.net   ->  

Хостинг - VPS с Докером. Я рассматриваю следующую схему:

1. Единственный контейнер с Nginx для обработки всех запросов
2. N копий контейнера с кодом и настройками сервиса — по одной для каждого домена
3. Единственная общая база данных (или другое хранилище)

Насколько жизнеспособен такой подход? Может быть есть известные проблемы? Как-нибудь это можно прооптимизировать — например, избежать копий контейнера с сервисом? Что-нибудь типа продвинутого конфига Nginx чтобы конвертировать URL и куки?

Заранее спасибо!

P.S. Для чего это нужно? Например, для обхода блокировок. Для предоставления того же сервиса через домен в зоне .onion. Подробнее о нашем проекте: https://deeptechgroup.net

Всем привет!

Мы представляем новую инициативу по созданию технического коллектива для решения конкретных задач – Deep Tech Group

https://deeptechgroup.net

http://deeptehvdjx3xbek.onion

Мы работаем над созданием технической базы сопротивления тотальному слежению и контролю. Под базой понимается коллектив IT-специалистов и энтузиастов, способных решать практические задачи, а именно:

• Проведение исследований в области информационной безопасности, приватности и анонимности
• Создание и развитие технических систем и средств защиты
• Предоставление сервисов людям и независимым сообществам, поддерживающим сопротивление тотальному контролю
• Просвещение людей в вопросах анонимности, приватности и безопасности

Уже есть конкретные идеи сервисов и проектов (самый важный – дополнение Tor системой, вносящей задержки — для повышения устойчивости к атакам шейпинга траффика и атакам пересечения).

Мы собираем открытое сообщество, поэтому будем рады всем IT-специалистам – админам и хакерам, разработчикам и web-дизайнерам. Присоединяйтесь!