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.
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.
[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.
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
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.
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
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?
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.
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.