Обнаружение и блокировка трафика VPN, Tor и прокси-серверов во время регистрации пользователей, входа в систему и/или глобально с использованием API ProxyTracer.
Этот плагин использует API ProxyTracer для обнаружения и блокировки трафика VPN, Tor и прокси-серверов в Discourse.
Возможности
Предоставляет гибкий контроль над блокировкой пользователей VPN, Tor и прокси-серверов при регистрации новых пользователей, аутентификации существующих пользователей или глобально для всех посетителей сайта. Если вы допускаете наличие у пользователей VPN, Tor и прокси-серверов прав на чтение вашего форума, вы можете сэкономить запросы к API и включить защиту только для регистрации и аутентификации пользователей.
Использует кэширование для хранения результатов недавних проверок IP-адресов, что снижает количество запросов к API и уменьшает задержки. Вы можете настроить срок хранения результатов проверки IP-адреса в настройках.
В случае тайм-аута API или сбоя сети плагин приоритизирует доступ пользователей, чтобы предотвратить массовую блокировку. Это поведение можно изменить через настройки.
Встроенная поддержка точного добавления IP-адресов и подсетей CIDR в белый список.
Перейдите в панель администрирования Discourse: Администрирование → Плагины → ProxyTracer, чтобы найти настройки ProxyTracer.
Введите ваш API-ключ в поле API-ключ ProxyTracer.
Включите параметры защиты, переключив Включено при регистрации, Включено при входе и/или Включено для всех посетителей.
Добавьте доверенные IP-адреса или диапазоны CIDR в список Белый список IP-адресов.
(Опционально) Отрегулируйте тайм-аут API и лимиты времени кэширования Redis в соответствии с требованиями трафика вашего сервера.
(Опционально) Настройте сообщение о блокировке, которое отображается заблокированным пользователям. Например, вы можете добавить инструкции по контакту с администрацией сайта, если пользователь считает, что блокировка необоснованна и он не использует прокси, Tor или VPN для доступа к сайту.
Время ожидания ответа от API перед истечением срока ожидания.
Длительность кэша (часы)
Время хранения IP-адреса перед повторной проверкой через API.
Открыть при ошибке
Если API аварийно завершает работу или истекает время ожидания, разрешить пользователю регистрацию/вход в любом случае, чтобы предотвратить блокировку всех пользователей.
Включено при регистрации
Блокировать прокси и VPN, когда новый пользователь пытается зарегистрироваться.
Включено при входе
Блокировать прокси и VPN, когда существующий пользователь пытается войти в систему.
Включено для всех посетителей
Блокировать прокси и VPN от доступа или просмотра любой страницы форума. (Предупреждение: это проверяет каждого посетителя и значительно увеличивает использование квоты API).
Сообщение о блокировке
Точное сообщение об ошибке, отображаемое пользователю при блокировке.
Белый список IP-адресов
IP-адреса или диапазоны CIDR (например, 192.168.1.0/24), которые строго разрешены для обхода блокировки.
Настройка сети: Cloudflare и обратные прокси
Для эффективной работы ProxyTracer приложение Discourse должно получать настоящий IP-адрес клиента.
Чтобы обеспечить правильную передачу IP-адреса, вы можете следовать этим подробным инструкциям.
Экстренный доступ
Если вы заблокировали себя, вы можете восстановить доступ, выполнив эти простые шаги.
Если вы хотите протестировать функциональность, вы можете зарегистрироваться в ProxyTracer и получить бесплатные кредиты API для тестирования.
Это зависит от ситуации. Существует настройка сайта, позволяющая отключить безопасный режим, что полезно для компонента с ограниченным доступом к темам и других компонентов/плагинов, которые пользователям не следует легко отключать таким образом (реклама, ограничение доступа для гостей и т. д.). Однако, если вы не авторизованы, это также затруднит использование безопасного режима администраторами. Я думаю, что они всё ещё могут включить его, используя вход в систему как администратор.
Для этого плагина, думаю, безопасный режим не поможет. Безопасный режим отключает только фронтенд-часть плагинов, а этот плагин написан на 100% на Ruby. Поэтому я не думаю, что отключение JavaScript-кастомизаций будет полезным. Этот факт, а также то, что плагин включает файл about.json, как будто он является компонентом темы, вызывает у меня некоторый скептицизм. Но в конечном счёте каждый сам отвечает за код, который устанавливает на своём форуме.
Вы абсолютно правы в этом, я могу подтвердить это на основе собственных тестов с только что запущенным экземпляром Discourse. Я обновил документацию инструкциями, которые действительно работают: вход на сервер и ручное отключение дополнения:
cd /var/discourse
./launcher enter app
rails c
SiteSetting.proxytracer_enabled = false
exit
exit
Я подтверждаю, что безопасный режим недоступен, когда включена настройка «Включено для всех посетителей», и кто-то пытается получить доступ к безопасному режиму, подключаясь через VPN/прокси.
Действительно, about.json избыточен для стандартных плагинов, я удалил его из репозитория.
Спасибо за всю вашу обратную связь @Moin. Если у вас есть другие замечания или предложения, не стесняйтесь оставлять их здесь. Код полностью открыт, и любой вклад приветствуется: GitHub - ProxyTracer/discourse-proxytracer.
Я тестирую ваш сервис и хотел бы узнать, есть ли какие-либо конфликты с файлом ‘templates/cloudflare.template.yml’ и будет ли плагин поддерживать возможные обновления ядра Discourse.
Спасибо за тестирование! Документация в README.md относительно интеграции с Cloudflare четко рекомендует включать "templates/cloudflare.template.yml", так как это необходимо для того, чтобы Discourse извлекал реальный IP-адрес пользователя, когда форум находится за Cloudflare. Таким образом, никакого конфликта с этим шаблоном нет, а его включение, напротив, обязательно.
И да, мы намерены следить за основными обновлениями Discourse, чтобы обеспечить полную совместимость с новыми версиями.
Я задумался о том, было бы хорошим компромиссом включить опцию, которая вместо блокировки пользователей требовала бы лишь прохождение hCaptcha, и сделать такую опцию значением по умолчанию. Она добавляет ровно столько трения, чтобы сделать жизнь спамеров и тех, кто пытается обойти бан, более сложной, при этом позволяя легитимным пользователям, которые хотят защитить свою конфиденциальность в сети с помощью VPN, Tor и подобных средств, продолжать пользоваться сервисом. Конечно, администраторы, которые по-прежнему хотят полностью блокировать эти сети, сохранили бы такую возможность. Что вы об этом думаете?
Большое спасибо! Я только что провёл тест в песочнице, и всё работает идеально.
Рассматриваете ли вы возможность добавления функции, связанной с IP-адресами и ASN мобильных сетей? На моём форуме часто возникает следующая ситуация: пользователь отключается от широкополосного соединения и переключается на 4G/5G-сеть оператора, чтобы получить другой IP-адрес, а затем пытается обойти ограничения на регистрацию или вход в систему Discourse.
Было бы полезно иметь возможность определять, когда IP-адрес принадлежит ASN мобильного оператора, и, по желанию, обрабатывать такие IP-адреса по-другому во время регистрации или входа в систему.
Возможно, это немного выходит за рамки функциональности ProxyTracer, поскольку не всегда связано с VPN или прокси, но это было бы полезно для решения конкретной проблемы того, как Discourse обрабатывает ограничения на количество аккаунтов с одного IP-адреса.
В случае с hCaptcha я уже использую его в своей установке, и он работает очень хорошо! Возможно, стоит объединить плагин, который, по всей видимости, уже входит в ядро Discourse, с вашим плагином, добавив, например, дополнительную функциональность.
Мне нравится идея сохранить полную блокировку, ведь в этом и заключается цель, но в отношении IPv4 и IPv6 для стационарных и мобильных сетей, похоже, будет очень полезно затруднить этот доступ с помощью задач, учитывая, что ИИ обожает создавать аккаунты на форумах.
Здравствуйте, спасибо, что приняли мой ответ в расчёт. Это действительно то, что меня интересует, и я считаю, что данная реализация является особенно чувствительной для всех, как для пользователей, так и для администраторов.
Честно говоря, я чувствую себя роботом, который выполняет капчи, чтобы доказать, что он человек, намеренно ведя себя как бот. В связанных темах я уже упоминал, что реализация Anubis (POW) кажется мне гораздо более приятной и функциональной.
Я понимаю, что это выходит за рамки данного проекта, но, судя по тому, что я могу проанализировать с моей позиции, использование упомянутой вами капчи было бы возможным и, по сути, не могло бы блокировать пользователей, которые ценят свою приватность и хотят вносить вклад, не будучи отторгнутыми.
Это интересный сценарий использования, и я понимаю ценность предоставления пользователям более детального контроля. Для этого потребовался бы совершенно новый эндпоинт API, так как эндпоинт v1 имеет довольно ограниченный охват и предоставляет только булево значение о том, является ли определённый IP-адрес прокси/VPN или нет.
У меня есть некоторые опасения относительно точности данных при попытке реализовать подобную функцию, поскольку точность определения того, используется ли IP-адрес в сетях 4G/5G, далека от идеала, и существуют приложения, в которых безобидные пользователи могут быть несправедливо наказаны, например, те, кто использует домашний беспроводной широкополосный интернет по 4G/5G.
Тем не менее, на данный момент фокус направлен на улучшение эндпоинта v1 API для расширения охвата.
Мы работаем над новым тестовым релизом расширения с опцией капчи и также рассматриваем эту функцию. Достаточно ли вам вкладки с такой информацией, или вы считаете, что мы можем добавить в неё больше столбцов?
@ProxyTracer У меня есть вопрос касательно использования запросов. Я заметил, что каждый раз при новом входе списывается один запрос, даже если сеть не является VPN/прокси. Это ожидаемое поведение?
Я понимаю, что при регистрации проверку нужно проводить в любом случае, и, скорее всего, это списывает один запрос с панели. Так и есть? Ведь если я настрою блокировку всех сайтов, используемых для таких проверок, то с моего пакета будет списано гораздо больше запросов, верно?
Я думал увеличить «Cache Duration hours» (время кэширования в часах) примерно до 30 дней, но кажется, что это не лучшая идея. Я ошибаюсь?
Да, чтобы определить, принадлежит ли входящий IP-адрес VPN/прокси или нет, плагин должен отправлять запрос к API ProxyTracer.
Однако результат (чистый IP или VPN/прокси) немедленно кэшируется в базе данных Redis вашего форума. Если тот же IP снова войдёт в течение заданного вами периода кэширования (в часах), Discourse предоставит ответ напрямую из Redis. Таким образом, запрос к API не будет засчитан. То же самое происходит, если вы включите опцию блокировки VPN/прокси со всех страниц сайта.
Блокировка на уровне посетителей потребляет больше запросов, чем защита только при входе, из-за анонимного трафика. Однако кэширование в Redis гарантирует, что повторные просмотры страниц возвращающимися посетителями никогда не будут генерировать ненужные списания запросов к API.
Динамические резидентные/мобильные IP-адреса периодически меняются, а новые выходные узлы VPN появляются со временем. Поэтому при кэшировании на 30 дней может случиться так, что ранее чистый динамический IP, который будет переназначен провайдеру VPN, не будет проверен повторно до истечения срока действия кэша. Именно поэтому значение в 4 дня будет гораздо лучше, чем 30 дней.
Для эффективной работы ProxyTracer приложение Discourse должно получать настоящий IP-адрес клиента.
