Discourse

Integrieren Sie ProxyTracer mit Discourse, um VPNs, Proxys und Botnets durch eine einfache Plugin-Installation automatisch zu erkennen und daran zu hindern, mit Ihrem Forum zu interagieren.

Das Plugin wird über dieses GitHub-Repository verteilt.

Funktionen

• Granulare Kontrolle, die es Administratoren ermöglicht, die IP-Validierung bei Neuregistrierungen, bei der Authentifizierung bestehender Benutzer oder global für alle Seitenbesucher durchzusetzen.
• Integriertes Redis-Caching speichert kürzliche IP-Adressbewertungen, reduziert externe API-Aufrufe drastisch und gewährleistet keine Latenz.
• Bei einem API-Timeout oder Netzwerkausfall priorisiert das Plugin den Benutzerzugang, um großflächige Aussperrungen zu vermeiden. Dieses Verhalten kann über die Optionen geändert werden.
• Speichert IP-Ergebnisse zwischen, um die Seitenleistung zu maximieren.

Installation

1. Führen Sie den Installationsbefehl aus

   cd /var/discourse

2. Aktivieren Sie das Plugin.

   nano containers/app.yml

3. Suchen Sie den Abschnitt hooks und fügen Sie den Repository-Klonbefehl direkt unter der docker_manager-Installation ein:

   hooks:
     after_code:
       - exec:
           cd: $home/plugins
           cmd:
             - git clone https://github.com/discourse/docker_manager.git
             - git clone https://github.com/proxytracer/discourse-proxytracer.git

4. Speichern Sie die Konfigurationsdatei und bauen Sie Ihren Discourse-Container neu auf, um das Plugin zu kompilieren:

   ./launcher rebuild app

Konfiguration

1. Besorgen Sie sich einen Standard-API-Schlüssel vom ProxyTracer Dashboard.
2. Navigieren Sie zu Ihrem Discourse-Administrationspanel: Admin → Plugins → ProxyTracer, um die ProxyTracer-Einstellungen zu finden.
3. Geben Sie den API-Schlüssel ein.
4. Aktivieren Sie die Schutzparameter, indem Sie Bei Registrierung aktiviert, Bei Anmeldung aktiviert und/oder Für alle Besucher aktiviert umschalten.
5. Geben Sie Ihren ProxyTracer-API-Schlüssel ein.
6. (Optional) Passen Sie die API-Timeout- und Redis-Cache-Dauer-Limits an die spezifischen Datenverkehrsanforderungen Ihres Servers an.
7. (Optional) Passen Sie die Sperrnachricht an, die gesperrten Benutzern angezeigt wird. Sie können beispielsweise Anweisungen zur Kontaktaufnahme mit der Seitenverwaltung hinzufügen, falls Benutzer der Meinung sind, dass die Sperrung ungerechtfertigt ist und sie nicht über einen Proxy oder VPN auf die Seite zugreifen.

Netzwerkkonfiguration: Cloudflare & Reverse Proxys

Stellen Sie sicher, dass Cloudflare der einzige Anbieter ist.

Direkt hinter Cloudflare

Dies gilt, wenn Ihr Discourse-Server direkt mit dem Internet verbunden ist und Cloudflare ausschließlich für DNS und Edge-Proxying verwendet. In dieser Standardkonfiguration müssen Sie Discourse so konfigurieren, dass es den IP-Bereichen von Cloudflare vertraut und die echte Client-IP aus den eingehenden Headern extrahiert.

1. Verbinden Sie sich per SSH mit Ihrem Server und bearbeiten Sie Ihre Container-Konfiguration: nano /var/discourse/containers/app.yml
2. Stellen Sie sicher, dass CF-Connecting-IP durchgereicht wird.

   templates:
     - "templates/postgres.template.yml"
     - "templates/redis.template.yml"
     - "templates/web.template.yml"
     - "templates/web.ratelimited.template.yml"
     - "templates/cloudflare.template.yml"

3. Speichern Sie die Datei und bauen Sie den Discourse-Container neu auf, um die Änderungen anzuwenden: ./launcher rebuild app

Mehrschichtige Proxy-Architektur (Cloudflare + lokaler Reverse Proxy)

Dies gilt, wenn Ihre Discourse-Instanz über ein lokales Server-Management-Panel oder einen Reverse Proxy (z.B. CloudPanel, Nginx Proxy Manager, Traefik, Plesk) geleitet wird, der hinter Cloudflare sitzt. In einer mehrschichtigen (oder „doppelten") Reverse-Proxy-Architektur wird das Standard-Discourse cloudflare.template.yml fehlschlagen, da der Datenverkehr von Ihrer lokalen Netzwerkschnittstelle an Discourse übergeben wird, nicht direkt von Cloudflare. Verwenden Sie das Cloudflare-Template in diesem Szenario nicht.

Stattdessen müssen Sie Ihren lokalen Reverse Proxy so konfigurieren, dass er die echte Client-IP aus dem Header CF-Connecting-IP extrahiert, aber nur für Datenverkehr, der von vertrauenswürdigen Cloudflare-IP-Adressen stammt. Diesen Header blind weiterzuleiten, ohne die Quelle zu überprüfen, ermöglicht es böswilligen Benutzern, Ratenlimits und Sperren zu umgehen, indem sie ihre IP-Adresse fälschen.

# IPv4 Cloudflare IPs, see https://www.cloudflare.com/ips/
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 104.16.0.0/13;
set_real_ip_from 104.24.0.0/14;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 131.0.72.0/22;
 
# IPv6 Cloudflare IPs
set_real_ip_from 2405:b500::/32;
set_real_ip_from 2405:8100::/32;
set_real_ip_from 2803:f800::/32;
set_real_ip_from 2c0f:f248::/32;
set_real_ip_from 2a06:98c0::/29;
 
real_ip_header CF-Connecting-IP;

Suchen Sie als nächstes Ihre Direktive location / oder @reverse_proxy. Aufgrund der obigen Konfiguration wird Nginx jetzt $remote_addr sicher zur echten Client-IP auflösen, nur wenn die Anfrage tatsächlich durch Cloudflare geleitet wurde. Ändern Sie Ihre IP-Weiterleitungs-Header wie folgt:

location / {
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 
    ...    
}

Speichern Sie die Konfiguration und laden Sie den Nginx-Dienst Ihres Hosts neu. Ein Neuaufbau des Discourse-Containers ist für diesen Schritt nicht erforderlich.

Validierung & Tests

Um zu überprüfen, ob Ihre Netzwerkkonfiguration die richtigen Daten erfolgreich an ProxyTracer weiterleitet:

1. Navigieren Sie zu Ihrem Discourse-Administrations-Dashboard: Admin → Users.
2. Überprüfen Sie die Spalten Registration IP oder Last IP für kürzliche Aktivitäten.
   • Fehlerhafte Konfiguration: Wenn Sie Cloudflare-IPs (siehe hier für die vollständige Liste) oder lokale Netzwerk-IPs (z.B. 127.0.0.1, 172.x.x.x) beobachten, schlägt die IP-Weiterleitung fehl. ProxyTracer kann Ihre Seite in diesem Zustand nicht schützen.
   • Korrekte Konfiguration: Wenn Sie standardmäßige, einzigartige private IP-Adressen beobachten, ist Ihre Netzwerkarchitektur korrekt konfiguriert und ProxyTracer überwacht aktiv Ihren Datenverkehr.

Notfallzugriff

cd /var/discourse
./launcher enter app
rails c
SiteSetting.proxytracer_enabled = false
exit
exit

Lizenz

Dieses Plugin ist unter der GNU Affero General Public License v3.0 (AGPLv3) lizenziert.