So lösen Sie das Problem des Quell-IP-Lecks und DD-Angriffe selbst bei Nutzung von Cloudflare CDN

Meine Website nutzt Discourse. Anfangs war sie nicht durch Cloudflare geschützt und wurde Opfer eines DDoS-Angriffs.

Später änderte ich die IP-Adresse und implementierte Cloudflare. Die Website wurde jedoch erneut von DDoS angegriffen, scheinbar aufgrund einer Leckage der IP des Ursprungsservers.

Wie können wir bei der Verwendung von Cloudflare CDN verhindern, dass die IP des Ursprungsservers durchsickert? Hat jemand gute Methoden? Danke.

Ich weiß es nicht, aber die IP-Adresse jedes Online-Servers wird gleichzeitig preisgegeben, wenn er erstellt wird.

Sie können viel Leckagen verhindern, indem Sie Folgendes tun

  • Richten Sie einen Proxy-Server wie Tinyproxy auf einem anderen VPS ein
  • Setzen Sie die Umgebungsvariablen HTTPS_PROXY und HTTP_PROXY, damit Discourse diese verwendet (setzen Sie sie im Abschnitt env Ihrer app.yml)
  • Setzen Sie NO_PROXY='127.0.0.1, localhost, <internes-Netzwerk>'

Siehe auch Install discourse with internet access only via proxy, Configuration outbound proxy und Discourse Link previews through a proxy server? - #14 by supermathie

Außerdem können Sie, wenn Sie sich hinter CF befinden, die Firewall auf Ihrem Discourse-Host ändern, um nur eingehenden Datenverkehr von Ihren Cloudflare-IPs (und dem Host, von dem aus Sie selbst darauf zugreifen) zuzulassen.

4 „Gefällt mir“

Das ist die Lösung. Sicherheit durch Verheimlichung ist nicht sicher. Dann spielt es keine Rolle, ob Ihre IP-Adresse allgemein bekannt ist.

3 „Gefällt mir“

[quote=„Richard – Communiteq, Beitrag:3, Thema:326476, Benutzername:RGJ“]Sie können die Firewall auf Ihrem Discourse-Host so ändern, dass nur eingehender Datenverkehr von Ihren Cloudflare-IPs zugelassen wird.
[/quote]

Dies oder alternativ ein einfacherer Ansatz wäre die Verwendung eines sogenannten Cloudflare-Tunnels. Dies sollte eine einmalige Einrichtung sein und dann sollten Sie Ihre Firewall für eingehende Verbindungen größtenteils schließen können.

2 „Gefällt mir“

Ich glaube, ich habe mich vor einiger Zeit dafür entschieden (ohne die von Ihnen erwähnte Proxy-Einrichtung). Ich bin mir nicht sicher, ob dies für alle Firewalls gilt (oder vielleicht etwas in meiner Einrichtung), aber in meinem Fall mit ufw umgeht Docker standardmäßig ufw, sodass Sie die Regeln auch auf Ihre internen Docker-IPs anwenden müssen. Es ist schon eine Weile her, aber ich kann mich später diese Woche genauer darum kümmern, wenn Sie dies noch benötigen. Und ja, Cloudflare Tunnels sind fantastisch! @itsbhanusharma

1 „Gefällt mir“

Sie sollten die Firewall verwenden, die Ihr VPS-Anbieter Ihnen zur Verfügung stellt. Die Verwendung einer hostbasierten Firewall ist bei der Bekämpfung von DDoS-Angriffen weitaus weniger effektiv, da der Datenverkehr Ihren Netzwerkstapel erreicht.

3 „Gefällt mir“

Ich denke, die meisten großen Anbieter bieten standardmäßig DDOS-Schutz an? Sollte das nicht ausreichen? Das Hinzufügen von CloudFlare IP-Adressen manuell über die Benutzeroberfläche erscheint mühsam (mein benutzerdefiniertes Bash-Skript dauert 2 Sekunden und ruft beispielsweise automatisch die CF-IPs ab).

Ich muss sagen, dass ich normalerweise das Gegenteil lese, ufw/lokale Firewall gegenüber der Firewall des Anbieters :thinking:

Bearbeitung; Ich verstehe die Logik hier, aus DDOS-Perspektive ist das wahrscheinlich effektiver und Sie haben Recht. Nichtsdestotrotz, wenn die Haupt-IP von Anfang an korrekt verborgen ist, sollte DDOS kein Problem sein, oder?

1 „Gefällt mir“

Die meisten Anbieter haben heutzutage eine API dafür?

Korrekt! Aber das ist ein ziemlich großes “Wenn”…

2 „Gefällt mir“

Eigentlich falsch. Nur weil die IP nicht versteckt ist. DDoS ist kein Problem, wenn ein Reverse-Proxy oder ähnliches Tools hat, um es zu stoppen. Und selbst dann, wenn es einen echten Angriff gibt, wird mehr als eine Einsteigerlösung benötigt. Und wenn Bots oder Sklavenbenutzer geschlossene Ports oder IP-begrenzte Ports anklopfen, ist das kein so großes Problem. Ich würde es als einen weiteren Donnerstag in der WordPress-Welt bezeichnen, aber Discourse ist in vielerlei Hinsicht eine andere Welt.

Andererseits bin ich kein Experte dafür.

Aber ich bin neugierig… wie viel Traffic wird benötigt, damit DDoS erfolgreich ist? Natürlich hängt es von den Ressourcen des Setups ab, aber bitte geben Sie mir einige Zahlen.

1 „Gefällt mir“

Es hängt von Ihrer Definition von versteckt ab. Ja, alle IP-Adressen sind öffentlich. Aber welche der 4 Milliarden IP-Adressen ist dann die richtige? Ich denke, für diese Diskussion kann die IP als versteckt betrachtet werden, wenn es keine Möglichkeit gibt, die IP-Adresse(n) für einen Server zu ermitteln, der ein bestimmtes Discourse-Forum bereitstellt (also ist die Funktion f(h) unbestimmt, wobei Funktion f Ihnen die tatsächliche IP-Adresse für einen Host gibt).
Vorausgesetzt:

  • dass Sie nicht Cloudflare sind
  • das Forum seine IP nicht durch ausgehenden Datenverkehr wie Oneboxing oder ausgehende E-Mail-Header oder auf andere Weise preisgibt

Aber ich stimme Ihnen zu, dass “versteckt” ein verwirrender und falscher Begriff ist. “Unbekannt” ist wahrscheinlich besser.

Das hängt von der Art des DDoS ab. Bei einem Angriff auf der Anwendungsebene mag das zutreffen, ist aber auch schwierig, da er eine Art Ratenbegrenzung mit Anfrageinspektion erfordern würde. Aber bei einem Angriff auf der Netzwerkebene (einfache Verkehrsüberflutung durch Amplifikation oder einen Syn-Angriff) gilt dies möglicherweise nicht. Außerdem sagen Sie im Grunde: “Es ist kein Problem, wenn man es abwehren kann”, was offensichtlich ist, aber auch schwierig und/oder teuer.

Es hängt auch von der Art des Angriffs ab. Ein Angriff auf der Anwendungsebene müsste auf Discourse zugeschnitten sein, könnte aber beispielsweise einige rechenintensive Abfragen wie Suchen ausführen, um die Anwendungsserver zu überlasten, während ein Angriff auf der Netzwerkebene allgemeiner sein kann, mehr Verkehr erzeugt und einfach Nginx oder das Netzwerk des VPS verstopfen kann.

4 „Gefällt mir“

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.