Всем привет!
Мы разрабатываем новое 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
- маршрутизирует траффик в соответствии с конфигурацией (т.е. различные целевые сайты могут получать данные по разным путям)
Вопросы
-
Мы будем рады конструктивной критике нашего подхода. Конкретные вопросы, которые пока не продуманы в архитектуре решения, ниже.
-
Стоит ли использовать докер-контейнеры для воркеров? Конечно, решение self-hosted, большой нагрузки не предполагается, но всё же. Польза в них видится в том, что там уже реализована виртуальная сеть, соответственно можно инстанциировать контейнеры с нужной конфигурацией сетей для маршрутизации траффика через сконфигурированный транспорт.
-
Если докер не использовать, то как тогда можно решить задачу маршрутизации? Грубо говоря, хотим один HTTP-запрос отправить через Tor + VPN к сайту A, а второй - через Tor + прокси к сайту Б.
-
Какая база данных лучше подойдет для данного проекта? Видятся два варианта - Postgres или MongoDB. Пока склоняемся к Монге, потому что будем хранить разнородные данные (посты, комменты, соообщения) из разных форумов, соцсетей, мессенджеров. Кажется, реляционная база принесет больше сложностей в разработке… При этом аналитика нормализованных данных не очень интересна в данном приложении (не первостепенна).
-
Какие браузерные (и небраузерные, когда это возможно) технологии автоматизации вы порекомендуете? Конкретно, для таких классов задач:
- автоматизация простых блогов, форумов (типа LOR, phpBB и др.)
- автоматизация джаваскриптовых соцсетей (типа VK, FB)
Спасибо!
