Mission Control: Wir lassen unsere Kunden niemals im Stich
Für einen Sicherheits- und Netzwerktechniker ist es wichtig zu wissen, wann etwas nicht stimmt. Es ist entscheidend, nicht aufzugeben, bis man die Ursache behoben hat – selbst wenn diese bei einem Drittanbieter liegt, der nicht der Meinung ist, dass es ein Problem gibt.
Mission-Control-Techniker wie ich geben nie auf, bis ein Problem zu unserer Zufriedenheit und zur Zufriedenheit unserer Kunden gelöst ist. Einer unserer Unternehmenswerte lautet: Kundenprobleme lösen, koste es, was es wolle. Diesen Wert leben wir jeden Tag.
Als ich zum ersten Mal die Fehlermeldung „NTP: NOT_SYNCED“ sah, dachte ich nicht, dass es zwei Monate und fast ein Dutzend Leute brauchen würde, um das Problem zu lösen.
NTP Network Time Protocol (NTP) ist ein Netzwerkprotokoll für die Uhrensynchronisation zwischen Systemen. Eine genaue und synchronisierte Zeit in einer Rechen- und Netzwerkumgebung ist von entscheidender Bedeutung. Beim Aufspüren von Netzwerkproblemen oder Eindämmen einer Cyberbedrohung ist es wichtig, genau zu wissen, wann etwas im Verhältnis mit anderen Ereignissen passiert ist. Ohne synchronisierte Zeit könnten koordinierte Prozesse fehlschlagen oder zeitbasierte Aktivitäten starten, obwohl es nicht an der Zeit dafür ist. Und Anwendungs-, Sicherheits- und Fehlerprotokolle haben falsche Zeitstempel, was sie weniger hilfreich oder nahezu nutzlos macht.
Wie bei allen anspruchsvollen Services von Open Systems laufen Engines auf wichtigen Systemen. Sie überwachen aktiv und passiv den Zustand der Service Delivery Platform (SDP). Bei Auftreten einer Fehlfunktion, z. B. wenn ein Service nicht ausgeführt wird, versucht die Engine, ihn zu reparieren und den betroffenen Service neu zu starten. Wenn dies nicht möglich ist, wird das Ereignis an eines unserer Mission Control Operations Center weitergeleitet, wo ein Ticket zur weiteren Untersuchung und Verarbeitung erstellt wird.
Ein lokaler Überwachungsprozess stellte fest, dass ein SDP seine Uhr nicht mehr mit öffentlichen Zeitservern synchronisieren konnte. In diesem Fall wurde das betroffene SDP auf einer VM von einem ISP gehostet. Es war das primäre Gateway zu einem verwendeten Service und ein kritischer Teil dieser Backend-Infrastruktur. Da ich für die Überwachung und Verwaltung dieses Service verantwortlich war, bin ich der Meldung „NTP: NOT_SYNCED“ nachgegangen.
Mein ursprünglicher Gedanke war, dass die Host-Konfiguration nicht korrekt war. Das war jedoch nicht der Fall, weil NTP mit derselben Konfiguration auf ähnlichen Cloud-Hosts arbeitete. Mein nächster Gedanke war, dass die Konfiguration mit dem ISP nicht korrekt war. Das war auch nicht die Ursache des Problems, da NTP auf seinem Peer einwandfrei funktionierte.
Es musste also etwas anderes sein. Nach einigen weiteren Untersuchungen und Paketverfolgungen auf dem NTP-Server (der Anfragen vom betroffenen Host empfängt und beantwortet) konnte ich bestätigen, dass der UDP-Verkehr (zumindest NTP und DNS) die verwendete Service-Plattform verlässt und erfolgreich von dem Server empfangen wird, der den NTP-Dienst bereitstellt, aber nicht von diesem Server zum betroffenen Host gelangt.
Meine Erfahrung sagte mir, dass das Problem nicht bei der SDP lag. Ich fing an, alle offenen Fragen auf der Plattform des Service-Anbieters durchzulesen, fand aber keine Antworten. Ich habe mehrere Stunden an dem Problem weitergearbeitet und gleichzeitig andere Tickets gelöst. Ich habe eine Firewall-Gruppe erstellt, die UDP-Port 123 zulässt. NTP ist ein UDP-basierter Service und verwendet den bekannten Port 123, um miteinander und mit NTP-Clients zu kommunizieren. Leider führte das in eine Sackgasse. Nach einigen weiteren Untersuchungen stellte ich fest, dass der zu verwendende ISP-Dienst überall DDoS-Schutz anwendet, auch wenn viele das nicht wissen. Nachdem ich das herausgefunden hatte, war ich ziemlich sicher, dass die Schwellenwerte für DDoS-Schutztrigger zu der Ursache des Problems gehören könnten.
Dann geschah etwas Beunruhigendes: „NTP:OK.“ Das bedeutet, das Problem ist technisch gelöst und NTP funktioniert wieder. Das Internet ändert sich ständig, was dazu führt, dass Probleme auftreten und verschwinden. Die Herausforderung besteht nun darin, die Ursache von etwas zu ermitteln, das plötzlich funktioniert. Obwohl ich die Kontrolle über einen Teil der Umgebung hatte, hatte ich keine Kontrolle über das Internet und schon gar nicht über die Infrastruktur beim ISP.
Wie es der Zufall wollte, tauchte 'NTP:NOT_SYNCED' wieder auf. Das war nur bedingt eine gute Nachricht, weil es bedeutete, dass ich etwas hatte, mit dem ich nur sporadisch arbeiten konnte. Die Zeit verging und der Fehler tauchte auf und verschwand wieder. Jeder, der schon einmal versucht hat, ein sporadisches Problem zu lösen, weiss, dass es ist, als würde man einen Geist jagen. Was es noch schlimmer machte war, dass ich keine Kontrolle über die gesamte Umgebung hatte. Ich musste mich mit dem Internet und einem Drittanbieter-ISP auseinandersetzen, der seine Plattform aus Sicherheitsgründen geschlossen hielt.
An diesem Punkt habe ich alles auf meiner Seite nochmals überprüft. Ich konnte nichts weiter tun. Ich konnte es nur an den ISP weiterleiten. Ich hatte mein „Monitoring-Setup“ mit Befehlen, die jede Sekunde ausgeführt werden und Paketerfassungen auf dem Server. Jetzt musste ich warten, bis es wieder auftauchte, um meine Erfassung durchzuführen und sie an den ISP weiterzuleiten. Für diese Umgebung ist der ISP für das Netzwerk und das Hosting der VM für den Service verantwortlich. Glücklicherweise musste ich nicht lange warten, bis die Meldung „NTP:NOT_SYNCED“ wieder auftauchte und ich einen Fall beim ISP melden konnte.
Ich erhielt eine Benachrichtigung von einem Support-Mitarbeiter, der mich fragte, ob ich Zeit hätte. Es dauerte nicht lange, bis ich in einem Anruf mit sechs anderen Personen war, die für einen Drittanbieter-Auftragnehmer arbeiten, der für den Support auf erster Ebene für den ISP verantwortlich ist. Ich war froh, dass ich das Problem besprechen konnte und erklärte meinen DDoS-Verdacht. Ich war zuversichtlich, dass das Problem gelöst werden konnte, wenn nicht bis zum Abend, dann bis zum Ende der Woche.
Das war ein Irrtum. Sie verstanden das Problem nicht. Es folgte eine frustrierende Reihe von Support-Anrufen, Konferenzen und E-Mails. Sie gaben mir immer wieder die Befehle, die zur Fehlerbehebung von TCP oder ICMP nützlich sind, aber sie sagten mir nicht, welche Befehle es für UDP sind. NTP ist UDP, das ist was betroffen war. Mir wurden unzählige Fragen gestellt, die – wenn man weiss, wie UDP und Networking im Allgemeinen funktionieren – nicht zu einer Lösung des Problems führen würden. Ich wurde gebeten, hier und da in ihrem Kundenportal zu klicken, ohne Erfolg. Es handelte sich dabei um all die Schritte, die ich bereits vor Meldung des Falls unternommen hatte. Aber ich respektiere, dass sie einem Prozess folgen und tat geduldig, worum sie mich baten und gab ihnen alle angeforderten Informationen.
Ich erwähnte dann noch einmal, dass ich festgestellt hatte, dass der verwendete Service bei Bedarf überall DDoS-Schutz anwendet, falls sie das vielleicht nicht wissen. Und ob das vielleicht die Ursache für die Umschaltung der NTP-Synchronisation-Kommunikation sein könnte.
Der Support-Mitarbeiter auf der ersten Ebene wusste nicht weiter und fragte seinen Vorgesetzten, der aber auch nicht mehr wusste. Man kann es sich kaum vorstellen, aber der E-Mail-Thread war so lang, dass ich keine Antworten mehr schreiben konnte. Die E-Mail-Anwendung reagierte nicht mehr und musste neu gestartet werden.
Zu diesem Zeitpunkt wurde unser ISP-Beziehungsmanager involviert, mit noch mehr E-Mails hin und her und Anrufen an den Auftragnehmer für den Support auf erster Ebene. Leider behielt „NTP: NOT_SYNCED“ die Oberhand. Trotzdem wurde die Weiterleitung an die Ingenieure vom ISP selbst abgelehnt. Es wurde behauptet, dass die verwendeten Server zu stark waren, um diese Art von Problemen zu verursachen. Sie untersuchten auch nicht die Möglichkeit, dass die DDoS-Konfigurationsschwellenwerte, wie ich vorgeschlagen hatte, das Problem verursachen könnten.
Um zu verstehen, wie schlecht die Unterstützung auf der ersten Ebene bei der Behebung realer Probleme funktioniert, ist es wahrscheinlich am besten, dies anhand eines Beispiels zu erläutern:
- Ich schreibe um 8:00 Uhr morgens an unseren Support-Vertreter auf der ersten Ebene, um ihm mitzuteilen, dass das Problem weiterhin besteht. Der dem Fall zugewiesene Vertreter ist immer derselbe. Manchmal hat man Glück mit jemandem, der kompetent und unermüdlich ist, aber das ist in der Regel nicht der Fall.
- Ich erhalte die automatische Antwort: Ich bin von Montag bis Freitag von 12:30–09:30 Uhr (IST) (GMT+5:30) verfügbar.
- Schliesslich erhalte ich eine Nachricht und er fragt, ob das Problem noch besteht. Ich bestätige.
- Eine Stunde später erhalte ich eine Antwort: „Ich beauftrage das interne Team mit der Paketerfassung.“
- Zwei Stunden später frage ich nach dem Status. Die Antwort lautet: „Ich warte immer noch auf eine Antwort des internen Teams.“
- Weitere 3 Stunden später: „Das interne Team für die Erfassungen ist jetzt bei uns. Stehen Sie jetzt zur Verfügung?“ Ich antworte „Ja.“
- Mehrere Chats und eine weitere Stunde später: „Sie richten jetzt den Zugriff ein – geben Sie uns ein paar Minuten.“
- Schliesslich, um 19:00 Uhr (vergessen Sie nicht, dass ich um 08:00 Uhr meine erste E-Mail des Tages geschrieben habe), liegt die Erfassung vor.
- Am nächsten Tag frage ich nach dem Status der Analyse. Die Antwort: „Die Erfassung wird noch überprüft.“
- So ging es immer weiter und und ich verbrachte Stunden damit, einen 1st-Level-Support-Vertragspartner zu unterstützen, aber ohne jeden Erfolg.
- Und dann erhielt ich um 13:41 Uhr folgende E-Mail: Hallo Christian, beim Call für die Fehlerbehebung mit dem Team hat sich gezeigt, dass wir kein Problem mit unserem Service feststellen konnten. Wir haben alle möglichen Schritte zur Fehlerbehebung ausprobiert, um das Problem einzugrenzen. Da die Pakete unseren Service verlassen haben (unter Verwendung von VM- und Host-Erfassungen), kommen wir zu dem Ergebnis, dass das Problem nicht bei unserem Service liegt. In diesem Fall kann daher keine weitere Fehlersuche durchgeführt werden. Bitte entschuldigen Sie die entstandenen Unannehmlichkeiten. Vielen Dank für Ihre Bemühungen und den Support bei der Fehlersuche.
Wie Sie sich vorstellen können, war ich extrem frustriert, zumal ich erklärte, dass die wahrscheinliche Ursache des Problems mit DDoS zusammenhängt und dass es von irgendwo in ihrer Umgebung kommt.
Zu diesem Zeitpunkt, nachdem meine letzten Bemühungen fehlgeschlagen waren, kontaktierte ich unseren Kundenbetreuer. Obwohl die SDP noch funktioniert hat, hatten wir zu viel Zeit mit dem Monitoring der Probleme der NTP-Synchronisierung verbracht und wir brauchten eine Lösung.
Es funktionierte. Ich habe endlich einen Support-Ingenieur der ersten Ebene vom ISP. Jemand, der auf E-Mails antwortet und das Problem verstanden hat Aufgrund des Zeitunterschieds zwischen unseren beiden Standorten dauerte es noch mehrere Nachtschichten lang, aber am 07.09. um 20:06 kam die gute Nachricht.
„Ja, wir haben etwas gefunden“, und später um 21:09 Uhr: „DDoS ist das Problem, beide VIPs haben unsere Schwellenwerte für Basis-PIP überschritten.“
Ich war erleichtert. Ich hatte bereits am ersten Tag bei Eröffnung des Tickets vermutet, dass DDoS das Problem war und dies mehrmals gegenüber dem 1st-Level-Support-Mitarbeiter erwähnt. Das wurde jedes Mal bestritten. Glücklicherweise konnte der ISP das Problem reproduzieren.
Um Ihnen einen technischen Hintergrund zu vermitteln: Einige IPSs haben Plattformen mit integriertem DDoS-Schutz. Da es sich um eine interne Ausfallsicherung in der Plattform handelt, erhält niemand in den Support-Teams Warnungen oder Metriken, falls der Schutzmechanismus ausgelöst oder freigegeben wird. In vielen Fällen ist es ein festgelegtes Limit für TCP und UDP. In diesem Fall sind der UDP-Traffic und der Schwellenwert unabhängig vom Host-Traffic ein fester Wert. Aus Sicherheitsgründen werden diese Werte nicht veröffentlicht. Nach dem Auslösen ist der gesamte UDP-Verkehr, einschliesslich DNS und NTP, begrenzt. Wenn der Verkehr abnimmt, stoppt der Schutz. Dies erklärt das Umschalten des NTP-Service beim Ein- und Ausschalten des DDoS-Schutzes.
Am Ende haben wir das Problem behoben und die Konfigurationen und Einstellungen geändert, um zu verhindern, dass die Probleme bei der NTP-Synchronisierung jemals wieder auftreten.
Wenn Sie bei Open Systems ein Ticket einreichen, wird es direkt von einem Techniker der Ebene 3 bearbeitet. Wir geben nicht auf, bis wir ein Problem gelöst haben. Es spielt keine Rolle, ob das Problem in der Kundenumgebung, beim Drittanbieter oder irgendwo im Internet liegt. Wir setzen uns auf allen Ebenen dafür ein, die Sicherheit unserer Kunden mit grösster Sorgfalt zu gewährleisten.
Lassen Sie die Komplexität
hinter sich
Sie möchten auch von der Open Systems SASE Experience profitieren? Unsere Experten helfen Ihnen gern weiter.
Kontakt