Startseite > Datacenter & Verkabelung > Wie man mit Testen ein Netz lahmlegt

Kommentar: Fehleranalyse

Wie man mit Testen ein Netz lahmlegt

16. Februar 2015, 13:44 Uhr | Mathias Hein, freier Consultan in Neuburg an der Donau

Fortsetzung des Artikels von Teil 1

Kleine Ursache - große Wirkung

Nach einem offen und ehrlich geführten Gespräch fanden wir heraus, dass unser "lieber" Anwendungsentwickler gerade dabei war eine neue Anwendung zu testen. Da es sich bei der neuen Anwendung um ein recht simples Programm handelte, fand er es nicht lohnenswert, diese im zwei Stockwerke tiefer liegenden Testlabor auszuprobieren. Stattdessen testete er die neue Anwendung auf seinem eigenen Computer.

Das Programm verschickte einen Multicast-Stream. Er wusste was er tat und nutzte nicht die Multicast-Adressen 224.0.0.1 beziehungsweise 224.0.0.2, die alle Hosts beziehungsweise alle Router adressierten. Stattdessen nutzte er die Multicast-Adresse 224.0.0.5.

Er erklärte mir, dass das Programm nicht viel Verkehr erzeugen würde. Er hatte den Parameter so gesetzt, dass alle drei Sekunden ein Paket in das Netz übertragen wurde. Während mein "lieber" Anwendungsentwickler dies erklärte, stutzte er kurz und sagte: "Vielleicht bedeutete dieser Parameter auch Millisekunden statt Sekunden..."

Kleine Ursache – große Wirkung! Leider gibt es wenige Möglichkeiten, ein Netzwerk gegen solche Zufälle zu wappnen. Die klassischen Port-Security-Mechanismen greifen hier nicht. Die Beschränkung der MAC-Adressen pro Port verhindert das Aufschalten von Hubs und Angriffe auf CAM-Tabellen. Access-Listen? Theoretisch ja, aber wer legt fest, welche Adressen und welche Anwendungen blockiert werden? Broadcast-Unterdrückung (okay, Multicast in diesem Fall) hätte das Verkehrsaufkommen begrenzt und könnte sogar den Switch-Port bei Bedarf abgeschaltet.

Vielleicht sollten wir in Zukunft diese Funktion öfter nutzen und das Netzwerk zusätzlich vor solche Attacken schützen. An manche Funktionen denkt man nicht bevor man sie braucht. In gewisser Weise war es sogar Glück, dass der Anwendungsentwickler die Zeiteinheiten durcheinander gebracht hatte und statt alle drei Sekunden alle drei Millisekunden Pakete verschickt hatte. Bei einer niedrigeren Netzlast hätten wir den Multicast-Verkehr nicht bemerkt. Der "liebe" Anwendungsentwickler hätte sich auch weiterhin nichts dabei gedacht, die Testterei im Live-Netzwerk durchzuführen. Hoffentlich haben die Entwickler für die Zukunft ihre Lektion gelernt und führen ihre Teste nun in dem isolierten Testnetz durch.