LINUX.ORG.RU

Подскажите по архитектуре для сервер-сайд клиента (автопостера) для мессенджеров, форумов, блогов, соцсетей

 , , ,


1

4

Всем привет!

Мы разрабатываем новое 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
  • маршрутизирует траффик в соответствии с конфигурацией (т.е. различные целевые сайты могут получать данные по разным путям)

Вопросы

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

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

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

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

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

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

Спасибо!

Попробуй mongo, но будь аккуратен. Не знаю, как сейчас, но в 2015 году она падала просто так на ровном месте. Плюнули и вернулись к MySQL.

fman2
()
Ответ на: комментарий от Int0l

Согласен. Поэтому многие советуют pg вместо монги... Своего собственного опыта мне не хватает, чтобы как-то решить :) но любой из вариантов будет работать, так что не супер-критично.

deeptechgroup
() автор топика
Ответ на: комментарий от PatrickKilpatrick

Вы наверно судите по тому, что часто их оставляют торчащими в сеть. У нас приложение будет полностью server-side, без клиентского js, поэтому такой конфигурации нам точно не нужно. А в остальном не думаю, что она более дырява чем Postgres.

deeptechgroup
() автор топика
Ответ на: комментарий от fman2

Не знаю, как сейчас, но в 2015 году она падала просто так на ровном месте.

Спасибо за информацию. Надеюсь, за 4 года стабилизировали :)

deeptechgroup
() автор топика

теперь роботы будут дочками офицеров, у которых не всё так однозначно?

spam, spam, spam, свободу спаму!

бойцам роботам информационного сопротивления - слава!

anonymous
()
Ответ на: комментарий от anonymous

Указывает настройки (параметры доступа к целевым сайтам и мессенджерам). Передает сообщение, которое нужно отправить; указывает, куда.

короче, юзер сам подставляется

anonymous
()
Ответ на: комментарий от PatrickKilpatrick

транзакцию и ради бога, конечно. Что за черт, почему нельзя редактировать-то?

PatrickKilpatrick
()
Ответ на: комментарий от anonymous

Спам и без нас процветает, этот инструмент ничего не добавит - арсенал спамеров на коммерческой основе очень активно развивается. Или взять решение капч...

deeptechgroup
() автор топика
Ответ на: комментарий от PatrickKilpatrick

Да, не хотелось бы терять конечно. Но в персональном инструменте не очень критично, наверно... хм.

deeptechgroup
() автор топика
Ответ на: комментарий от Deleted

Коммерческие (в основном облачные) решения существуют и работают. Так что ничего особо утопичного нет. Конечно, поддержать все соцсети и мессенджеры будет непросто, некоторые сопротивление окажут :)

deeptechgroup
() автор топика
Ответ на: комментарий от anonymous

Поэтому мы и говорим - self-hosted. То есть максимум кому подставляется - владельцам VPS. Но это уже приемлемый риск (обычно они не занимаются ловлей блох...)

deeptechgroup
() автор топика
Ответ на: комментарий от deeptechgroup

Оно будет завязано на постоянные обновления, без которых все сломается.

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.