12. März 2010

Gedanken zu Denial-of-Service

Category: Work — Christian @ 16:34

Ich überlege gerade für einen Freund, wie man eine Beschreibung von Denial-of-Service Angriffen (DDoS ist nur ein Randthema) und möglichen Gegenmaßnahmen sinnvoll gliedern kann. Meine Idee geht dazu, die verschiedenen Angriffsebenen als Gliederungspunkt heranzuziehen, weil man auf Netzwerkebene halt andere Gegenmaßnahmen hat und braucht als auf Anwendungsebene.

  1. Einleitung
  2. Definitionen
  3. DoS im Systembetrieb
    1. Redundante Netzverbindungen
    2. Redundante Stromversorgung
    3. Sonstige Hardware-Fehler
  4. DoS in der Netzwerkkommunikation
    1. DoS auf Layer 2 (ARP, …)
      Praktisch irrelevant, da Angreifer vor Ort sein müssten
    2. DoS auf Layer 3/4 (Smurf, Fraggle, Land, SYN-Flooding, …)
      Praktisch irrelevant, da von Firewalls zuverlässig erkannt und im OS gefixt (SYN-Flooding)
  5. DoS auf Betriebssystemebene
    1. OS resource exhaustion (RAM, CPU, …)
      Mehr eine Frage der Kapazitätsplanung
    2. Implementierungsprobleme
      Lösung könnte ein OS-Wechsel oder Stack-Tuning bringen
  6. DoS auf Anwendungsebene
    1. Application resource exhaustion (Memory Allocation, …)
      Programmierfehler, Code Analyse hilft
    2. Sonstige Fehler in Anwendungen
      Logikfehler, Concurrency, …
  7. DoS auf sonstigen Ebenen
    1. Benutzeraccounts blockieren
      DoS gegen Sicherheitsmaßnahmen
    2. Überlastung durch überraschendes Benutzerverhalten
      „Heise-DoS“, Frage der Kapazitätsplanung
  8. Distributed DoS
    1. DDoS auf Netzwerkebene
    2. DDoS auf Betriebssystemebene
    3. DDoS auf Anwendungsebene
  9. Gegenmaßnahmen
    1. Schutz auf Layer 2
    2. Schutz auf Layer 3/4
    3. Schutz auf Betriebssystemebene
    4. Schutz auf Anwendungsebene
  10. Kosten/Nutzen-Relation

Ist das sinnvoll? Habe ich was wichtiges vergessen?

Nachtrag:

Ideen von Tobias bereits eingearbeitet.

9 Comments

  1. Immer gerne gesehen: User aided denial of service 🙂 Will heißen: Sorge dafür, dass Nutzer aufgrund von E-Mail, Message-LED am Telefon, Nachrichten oder sonstigem einen Dienst überdurchschnittlich viel nutzen. Technisch aber letztlich ein DDos auf Anwendungsebene, wenn auch im Verlauf meist anders.

    Weiterhin ist der physische Angriff (Layer 0) auch immermal wieder am Start, z. B. Stecker ziehen

    Beides wirkt sich auf die Gegenmaßnahmen aus, da hier andere Mechanismen greifen.

    Comment by Tobias — 12. März 2010 @ 22:18

  2. Stimmt, Layer 0 ist ne gute Idee. Ich bin stillschweigend davon ausgegangen, daß die Systeme irgendwo in einem Rechenzentrum stehen aber das muß natürlich nicht immer der Fall sein. Sowas wie „Heise-DoS“ ist m.E. eine Frage der Kapazitätsplanung und Kosten-Nutzen-Relation. Das Blog hier würde 100 gleichzeitige User auch nicht überleben, weil dann die MySQL-Datenbank mangels genügend RAM in der Kiste abstürzt.

    Comment by Christian — 13. März 2010 @ 14:37

  3. Layer 0 im RZ: Putzdienst drückt den Notaus. Schon alles gesehen 🙂

    Bzgl. „Heise-Dos“: Das hat aus meiner Erfahrung raus durchaus Auswirkung z. B. auf Überlegungen von Entwicklern. Beispiel message waiting LED am Telefon. Entwickler: „Warum sollten wir die absichern, ist doch wurscht!“ Ich: „Wenn ich die Message spoofen kann, rufen plötzlich 50% der User den Voicemail-Server an.“ Entwickler: „Ups“.
    Bei reinen Webdiensten geb ich Dir recht 🙂

    Comment by Tobias — 13. März 2010 @ 17:44

  4. Ich glaube, hinter dem Telefonservice steckt in diesem speziellen Fall ein Callcenter. Das Heise-DoS ist im speziellen Fall auch kein Thema weil die Server für x-tausend User gedacht ist (x = viele). 😉
    Aber für eine generisch vollständige Liste nehme ich natürlich alles sehr gerne auf.

    Comment by Christian — 13. März 2010 @ 18:37

  5. >Ich glaube, hinter dem Telefonservice steckt in diesem
    >speziellen Fall ein Callcenter
    Nope. Snom, Cisco und andere sind anfällig (gewesen?). Damit macht der Angriff in sehr vielen VoIP-(V)LANs Spaß 🙂 Ein UDP-Päckchen pro IP und IP-Phone und schon düsen alle zum Voicemail-Server.

    Will also sagen: So mancher Entwickler hat keine Vorstellung davon, warum selbst die sicherheits-irrelevanteste Funktion sauber vor Missbrauch geschützt gehört. Ansonsten kann es u. A. einen User-DDoS geben.

    Comment by Tobias — 13. März 2010 @ 20:25

  6. Das „in diesem speziellen Fall“ bezog sich jetzt auf meine Ausgangsposition und die Rahmenbedingungen die mir geschildert wurden.

    Ich bin ja eh ein großer Freund von VoIP. Wenn das Netzwerk down ist, ruft wenigstens keiner mehr bei den Netzwerkadministratoren an um zu sagen, daß das Netz down ist.

    Comment by Christian — 13. März 2010 @ 20:34

  7. >Das “in diesem speziellen Fall” bezog sich jetzt auf
    >meine Ausgangsposition und die Rahmenbedingungen die
    >mir geschildert wurden.
    Deshalb ja nochmal die Details 🙂

    >Ich bin ja eh ein großer Freund von VoIP. Wenn das
    >Netzwerk down ist, ruft wenigstens keiner mehr bei den
    >Netzwerkadministratoren an um zu sagen, daß das Netz
    >down ist.
    Aus Sicherheitssicht eine mittelschwere Katastrophe dieses VoIP, aber sind wir ehrlich: Klassische Telefonie hat auch ihre Schwächen, die z. T. noch trivialer Auszunutzen waren. Aus Nutzersicht hat VoIP je nach Lösung extrem viel Charme. Wir nutzen z. B. eine Asterisk-basierte Lösung und ich bin Fan geworden. Mal zu erleben, dass „Konvergenz“ funktioniert ist ne tolle Erfahrung. Jahrelang hab ichs nur gelesen 🙂

    Comment by Tobias — 13. März 2010 @ 21:08

  8. Ja hmm. Konvergenz … funktioniert nur, wenn die Anwender auch mitspielen. Und manchmal weiß ich nicht, wie viel Konvergenz ich eigentlich will. SMS vom/zum Festnetz ist für mich so ein Beispiel. Mir persönlich behagt es nicht, wenn SMS von mir weil ich z.B. die falsche Nummer im Adressbuch ausgewählt habe, von einer Automatenstimme auf den Anrufbeantworter gesprochen wird. Egal.

    Comment by Christian — 13. März 2010 @ 21:20

  9. Kommentare gesperrt wegen Spam

    Comment by Christian — 20. April 2010 @ 16:25

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.