Обнаружение и блокировка трафика 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) кажется мне гораздо более приятной и функциональной.
Я понимаю, что это выходит за рамки данного проекта, но, судя по тому, что я могу проанализировать с моей позиции, использование упомянутой вами капчи было бы возможным и, по сути, не могло бы блокировать пользователей, которые ценят свою приватность и хотят вносить вклад, не будучи отторгнутыми.