Wie kompensiert man einen DDOS Angriff mit einer größeren Serverdienstkapazität?



  • Also wie muss man sich das vorstellen?

    Domain XY kann 5000 User verkraften und dafür sorgen 10 Rechner.

    Nun erfolgt ein DDOS und bringt den Dienst zum Erliegen.

    Der Betreiber vergrößert nun die Serverdienstkapazität auf weitere 20 Rechner, die fangen das ab und der DDOS kann nichts mehr ausrichten.

    Aber, wie wird das hostingseitig realisiert?
    Läuft auf jedem der 30 Rechner ein Webserver und wenn ja, arbeiten die dann alle mit einem einzigen Server zusammen, der die Datenbank verwaltet oder gibt es gleich mehrere Server mit jeweils einer Datenbank?

    Also wie muss man sich distributed Server Hosting vorstellen, wie wird das realisiert?



  • Die wichtigste Frage habe ich noch vergessen.

    Und wie sorgt man dafür, das immer ein anderer, wenig ausgelasteter Webserver auf eine Anfrage an die Domain reagiert?


  • Mod

    https://en.wikipedia.org/wiki/Content_delivery_network

    Aber sich auf diese Weise gegen DDOS zu schützen ist wie einen dickeren Rechner zu kaufen, wenn das System vor lauter Viren lahmt.



  • SeppJ schrieb:

    https://en.wikipedia.org/wiki/Content_delivery_network

    Aber sich auf diese Weise gegen DDOS zu schützen ist wie einen dickeren Rechner zu kaufen, wenn das System vor lauter Viren lahmt.

    Klar, man könnte natürlich noch Router davorschalten und die angreifenden IP Adressen für eine Gewisse Zeit aussperren oder, falls nur eine IP angegriffen wurde, die IP der Domain ändern.

    Dennoch gehört auch das zur gängigen Praxis wie es gemacht wird.
    Gegen viel hilft da einfach noch mehr.

    Danke übrigens für den Link.



  • und dann gibt's da auch noch firewalls 🙂



  • FW schrieb:

    und dann gibt's da auch noch firewalls 🙂

    Steht doch schon im Text:

    Klar, man könnte natürlich noch Router davorschalten und die angreifenden IP Adressen für eine Gewisse Zeit aussperren


  • Mod

    Vielleicht sollte man betonen, dass das ist, was man machen sollte (plus besser noch ein paar andere wirksame Maßnahmen).

    Wohingegen das Aufstellen von mehr Rechnern das Bekämpfen von Symptomen ist.



  • Distributed Hosting? schrieb:

    FW schrieb:

    und dann gibt's da auch noch firewalls 🙂

    Steht doch schon im Text:

    Klar, man könnte natürlich noch Router davorschalten und die angreifenden IP Adressen für eine Gewisse Zeit aussperren

    wenn man den unterschied zwischen einer statful firewall und paketfiltern nicht kennt, kann man das natuerlich so sehen. ansonsten aber nicht.



  • FW schrieb:

    Distributed Hosting? schrieb:

    FW schrieb:

    und dann gibt's da auch noch firewalls 🙂

    Steht doch schon im Text:

    Klar, man könnte natürlich noch Router davorschalten und die angreifenden IP Adressen für eine Gewisse Zeit aussperren

    wenn man den unterschied zwischen einer statful firewall und paketfiltern nicht kennt, kann man das natuerlich so sehen. ansonsten aber nicht.

    Ich kenne den Unterschied, das Problem liegt bei dir, da du Dinge in den Text hineininterpretierst die nicht dastehen.



  • Jo, zum Sperren von IPs braucht man nun wirklich keine "stateful" Firewall.
    Naja.

    Hilft aber alles nix, wenn der DOS so dick ist dass er die Pipe zumacht. In dem Fall hilft dann nur mehr ne dickere Pipe. Oder eben mehrere.

    Oder Zugriff auf irgendwelche Router im Backbone. Den man vermutlich nicht bekommen wird.



  • Achja, deine Frage war ja eigentlich eine ganz andere 🙂

    Distributed Hosting? schrieb:

    Aber, wie wird das hostingseitig realisiert?
    Läuft auf jedem der 30 Rechner ein Webserver und wenn ja, arbeiten die dann alle mit einem einzigen Server zusammen, der die Datenbank verwaltet oder gibt es gleich mehrere Server mit jeweils einer Datenbank?

    Also wie muss man sich distributed Server Hosting vorstellen, wie wird das realisiert?

    Das ist oft gar nicht so einfach.
    Und wie immer: es kommt drauf an.
    Auf die Art der Anwendung und natürlich darauf wie sie implementiert ist.

    Anwendungen wo die User mehr oder weniger getrennt nebeneinander her arbeiten, sind normalerweise kein schlimmes Problem. Daten auf die die User gemeinsam zugreifen kann man da normalerweise gut cachen bzw. replizieren. Beispielsweise ein Suchindex. Da stellst du halt mehrere Server hin auf denen der selbe Index drauf liegt, und dann nochmal mehrere Server mit denen die User sich verbinden. Wenn der Index nicht "live" ist, reicht das schon. Wenn der Index schon mehr oder weniger "live" sein soll, also dauernd indizierte Daten geändert werden, und diese Änderungen auch sofort in den Suchergebnissen aufscheinen sollen, dann muss man schon etwas tricksen. Wenn die Last nicht ZU gross ist, kann man einfach eine DB als Index verwenden, die man per Replizierung/Log-Shipping/... auf mehrere Such-Slaves "pusht". Wenn man dann die Grenze von so einem Setup erreicht hat, dann muss man zu ... "kreativeren" Lösungen greifen. Vorstellen könnte ich mir z.B. dass man den Index in einen "statischen" und einen dynamischen Teil splittet. Der "statische" Teil wird halt alle paar Tage mal komplett neu generiert und auf die verschiedenen Server verteilt. Und im dynamischen Teil erfasst man nur Dokumente wo sich seit dem letzten "rebuild" des statischen Teils etwas geändert hat.
    Suchen muss man dann in beiden Indexen, und danach das Ergebnis entsprechend "mergen".

    Ein echtes Problem sind aber Anwendungen wo die User sehr direkt mit sehr vielen anderen Usern interagieren. Stell dir z.B. ein Online Game vor mit einer offenen Welt ohne "Grenzen" (also ohne Portale/Tore/Eingänge/...) oder sonstige Unterteilungen (verschiedene Planeten/...). Wo die User frei rumlaufen können, Dinge nehmen (so dass sie für andere User dann nicht mehr da sind), abstellen (so dass andere User sie danach sehen/nehmen können), anderen Usern eins über die Rübe ziehen etc.
    Da gibt es dann keine "natürlichen" Grenzen mehr wo man das System auf mehrere Server aufteilen könnte.
    Was wohl auch der Grund ist dass es kaum solche Spiele gibt.

    Nochmal zurück zu dem was du geschrieben hast, also mehrere Application-Server mit einer zentralen DB. Wenn das geht, also wenn die zentrale DB stark/schnell genug ist um die Anfragen aller User gleichzeitig zu bedienen, dann ist das eine sehr einfache Lösung. Eignet sich aber nicht für alle Anwendungen, bzw. nicht ohne weitere Tricks. Und ... wenn man die Anwendung so programmiert dass der Datenaustausch quasi rein über die DB läuft, dann bekommt man eher das Problem dass die DB überlastet wird bevor der Application-Server in die Knie geht.



  • hustbaer schrieb:

    Jo, zum Sperren von IPs braucht man nun wirklich keine "stateful" Firewall.
    Naja.

    hab ich auch mitnichten behauptet. die gleichsetzung hat ja wohl 'Distributed Hosting?' gemacht. ich habe mich nicht im geringsten auf IP sperren bezogen.
    es gibt auch ddos-attacken, die nicht sinnvoll durch ip sperren behindert werden koennen. z.b. dann, wenn die source IPs gespooft werden. oder auch ddos die nicht ueber das traffic volumen funktionieren. 😮
    und jetzt stell dir vor, bei manchen dieser attacken koennen stateful firewalls ein angemessenes gegenmittel sein.


Anmelden zum Antworten