News Bahnfunk-Störung: Wenn ein Update den Bahnverkehr stoppt

[conf_t]

Die ganze Alu-Idee von ICE2 war wohl nicht ganz ideal. Das machte ihn für Seitenwinde zu leicht, weshalb er ewig im Schiebebetrieb nicht die gleiche Geschwindigkeit fahrendurfte wie im Zugbetrieb.

 

[Weyoun]

Wenn die fehlende Fehlermeldung im Fehlerfall dazu führt, dass vorhandene Redundanz ad absurdum geführt wird...

 

[RcTomcat]

Wir reden über einen Konzern, der jedes Jahr mit X Mrd. unterbudgetiert wurde. Jahrzehnte lang.

Wir reden von einem Konzern mit Milliardenbudget im KRITIS Bereich. Mit Vorständen welche Millionen bekommen. Eine AG welche sich zu 100% in Besitz des Bundes befindet und jährlich einen Milliardenzuschuss zum Erhalt der Infrastruktur erhält.
Geld ist hier die falsche Ausrede. Es ist eine Frage der Priorität und der Organisation. Zu behaupten es wäre kein Geld da um kritische Infrastruktur korrekt zu betreiben, wobei man zeitgleich 17 Millionen für Vorstände ausgeben kann, ist ein schlechter Scherz.
Allein schon die Tatsache, dass der Konzern 156 Millionen Euro an Entschädigungen im letzten Jahr gezahlt hat ist ein Schlag ins Gesicht jedes Steuerzahlers.
Überlege mal was da ein bundesweiter Ausfall auf einen Schlag kostet.

 

[xexex]

Aber genau da finde ich auch, das da einfach der Prozess bzw der Ablauf besser sein muss wenn die Meldung solcher Probleme angeblich so lange dauert.

Das wünscht man sich immer und meist bleibt es bei dem Wunsch. Beim nächsten mal wird man genau dieses Fall genau beobachten und es kommt was anderes, was man nicht berücksichtig hat. Egal wie gut der Plan ist, Murphy findet seinen Weg immer.

Jetz muss man natürlich klar eines berücksichtigen, es war wohl eher ein kleiner Schritt für den Techniker und ein großer für die Bahninfrastruktur. Wenn es ein komplexer Rollout gewesen wäre, würde man vermutlich alles besser prüfen und absichern.

Manchmal ist es aber halt eben so. Da will man abends nur ein Port in ein VLAN hinzufüge, ein Prozess den man schon zig mal gemacht hat und dann steht alles weil man den falschen Port erwischt hat. Der Verursacher wird sich sein Leben dran erinnern und zum Glück ist nichts passiert.

Ergänzung (29. Juni 2026)

Allein schon die Tatsache, dass der Konzern 156 Millionen Euro an Entschädigungen im letzten Jahr gezahlt hat ist ein Schlag ins Gesicht jedes Steuerzahlers.

Ach komm! Die Entschädigung ergibt sich aus der teilweisen Rückerstattung des Ticketpreises, das hat keinen Steuerzahler auch nur einen Cent gekostet, sie haben schlichtweg weniger Geld eingenommen als sie könnten. Bei einem Konzernumsatz von knapp 27 Mrd Euro, ist das Geld ganz woanders "versunken".

 

[Sierra1505]

Die DB ist ein dezentralisierter föderaler Konzern in dem allen voran „die IT“ und deren Resilienz bei genau solchen Fragen stark unter diesem System krankt.

Die DBInfraGO ist Hauptverantwortliche für den Betrieb des GSM-Netzes.

Die DB System GmbH betreut die internen Dienste, Rechenzentren, Serverstrukturen, Software etc.
Sie isolieren das Problem, prüfen Cyberangriffe, machen den Support und bearbeiten defacto das Ticket.

DB Fern und DB Regio-Verkehr (zwei separate Sparten) betreiben jeweils ihre Züge und sind von diesem Netz abhängig und Betroffene.

DB Cargo (Güterverkehr) das gleiche.

Und zu guter letzt das Konzernzentrum inkl. dem entsprechendem Board in Frankfurt die hier (meinen) effiziente, schnelle und praktikable Entscheidungen auf den Weg bringen.

Ich habe mal an einem Projekt mitgewirkt in welchem deutschlandweit hochrelevante aber massiv historisch gewachsene veraltete Infrastruktur erneuert werden sollte.
Dieses Projekt ist gescheitert bevor es begonnen hat.
Nicht am Projekt, sondern an den besagten Konzernstrukturen und dem aufgeblähten Entscheider-Assemble welches „Die Deutsch Bahn“ zu bieten hat.
Die Stimme mit der dieser Konzern in so relevanten Fragen wie der Konzern-IT-Integrität spricht ist so eins, wie die der Bundes-Kultusministerkonferenz im Fragen der landesweiten Bildung…

 

[conf_t]

Die DB System GmbH

Nein, die haben damit genau 0,000000% zu tun gehabt. Die Welt(?) hat das vor ein paar Tagen falsch kund getan und Rechenzentren haben die auch nicht. Die sind seit bald 10 Jahren Cloudfirst. Stand mal bei Heise.

 

[STM64]

Die DBInfraGO ist Hauptverantwortliche für den Betrieb des GSM-Netzes.

Das ist soweit mir bekannt ist, wie bei vielen europäischen Bahnbetreibern an den Marktführer aus Österreich Frequentis outgesourct. Die machen sowohl die Entwicklung, als auch die Wartung.

 

[dev/random]

Die Stimme mit der dieser Konzern in so relevanten Fragen wie der Konzern-IT-Integrität spricht ist so eins, wie die der Bundes-Kultusministerkonferenz im Fragen der landesweiten Bildung…

SCNR aber das klingt sehr nach "We are the Bahn. Resilience is futile"

 

[Hammelkoppter]

das ist mittlerweile ziemlich normal, dass Instandhaltungsarbeiten tagsüber während der Bürozeiten durchgeführt werden, da das die Zeiten sind, in denen notfalls der Supporter erreichbar ist Was nützt es, wenn an einem Sonntag führ um 2Uhr ein System ausfällt, der Dienstleister im Extremfall aber nicht vor Montag 8Uhr, oder bei erhöhtem SLA zwar "direkt" erreichbar ist, dieser aber aufgrund Wochenende und Uhrzeit erst mal selber nur langsamer reagieren kann (wie auch die eigene Firma, für den Fall, dass durch die Störung auch andere Systeme betroffen sind, die dann total untypischerweise auch noch gesondert beobachtet werden müsse), vor allem womöglich die Top-Leute gar nicht in Bereitschaft sind und man sich mit der zweiten oder dritten Garde für das Problem rumärgern darf?

1. Wir sprechen hier nicht von einem 0815 Büroswitch an dem ein paar Clients und Drucker dran hängen. Wer so einen Change plant, macht vorher eine Risikobewertung damit dieser überhaupt im CAB genehmigt wird. Hier wurde das Risiko entweder massiv runter gespielt oder vollkommen ignoriert.

2. Für solche Fälle gibt es eine Anlaufbegleitung dh. man vereinbart mit dem Dienstleister, dass man z.B. 24h nach dem Change noch eine Bereitschaft hat. Und auch die Leute, die diese Bereitschaft inne haben, sollten dann natürlich die Leute sein, die den Change durchgeführt haben bzw vol im Thema stecken. Das ist alles nur ne Frage zwischen Daumen und Zeigefinger. Da spielt auch Sonntag und die Uhrzeit überhaupt keine Rolle.

 

[cyberpirate]

Zum Zustand der Bahn will ich mal gar nix sagen. Da fällt mir auch nichts mehr zu ein. Was mir immer wieder in den Kopf kommt sind die armen Pendler die auf die bahn angewiesen sind. Wenn ich Bahn fahren müsste hätte Ich mir wohl schon längst einen Strick genommen. Einfach ABSURD das ganze.

Gibt es eigentlich keine Redundanz bei solchen Updates? So das man bei einem Fail direkt auf das funktionierende umswitchen kann?

 

[conf_t]

Gibt es eigentlich keine Redundanz bei solchen Updates? So das man bei einem Fail direkt auf das funktionierende umswitchen kann?

Hättest du dir mal die Mühe gemacht mehr als Headlines zu lesen wüsstest du, dass es natürlich eine Redundanz gibt und alle die täglich mit redundanten Systemen arbeiten, wie andere hier und ich wissen, dass für ein Redundanzversagen meist "seltesame" Zwischenzustände zuständig sind. (SW Bugs, aufgehängte Prozesse, PL auf Controllleitungen, Memory Leaks, (hat z.B. Cisco erst mit IOS-XE 16.12 ernsthaft in den Griff bekommen),....), wo die automatische Redundanzerkennung keinen Fall einer notwendigen Redundanz erkennt und somit nichts tut. Hätte bei der Bahn jemand den Switch nicht getauscht, sondern ausgebaut gelassen, hätte das sicherlich niemand funktioniert.

Und es wurde ja "schnell" auf Redundanz umgeschaltet.... aber da es viele Systeme (Annahme von mir, aber ich kenne so zentrale Systeme) im GSM-R Umfeld gibt die die Ursache hätten sein können muss jedes überprüft werden, welches von denen die versagende Redundanz ist.

Meiner Einschätzung nach ist sich das BMV – insbesondere in den Jahren unter CSU-Führung, aber auch schon zuvor in den 1990er Jahren – ebenso wie die Konzernspitze der Deutschen Bahn und die Leitungen der Geschäftsfelder nicht ausreichend bewusst, was es bedeutet, Betreiber Kritischer Infrastruktur (KRITIS) zu sein.Der permanente Kostendruck innerhalb des Konzerns, der maßgeblich durch die politischen Vorgaben des BMV geprägt wurde, trägt jedenfalls nicht dazu bei, eine wirklich resiliente Infrastruktur zu betreiben.

Dabei scheint häufig übersehen zu werden, dass eine Mobilisierung der Streitkräfte im Ernstfall in erheblichem Maße auf die Schiene angewiesen wäre - oder ein durchgeknallter amerikanischer Präsident würde ähnliches bedeuten. Die relevanten IT-Knotenpunkte und deren Standorte sind schließlich keine Staatsgeheimnisse - ohne IT steht alles, wie man sieht. Werden an den richtigen Stellen Ausfälle verursacht, kann das die Handlungsfähigkeit Deutschlands massiv beeinträchtigen - wie auch 2022, ich gehe da von Insiderwissen aus, sowas kann kein Zufall gewesen sein.Den konkreten GSM-R-Vorfall sehe ich dabei gar nicht als das eigentliche Problem.

Wer mit hochverfügbaren, redundanten Systemen arbeitet, weiß, wie schnell Redundanzmechanismen versagen können, wenn ein Fehler außerhalb der erwarteten Parameter (= "Fehler" oder "kein Fehler") liegt. Wenn die überwachte Metrik weiterhin "grün" ist, obwohl das System faktisch nicht mehr funktioniert, greift die Umschaltung möglicherweise nicht - sowas skaliert von ganz klein bis nach ganz groß - schon ein LACP kann hier ungeahnte Probleme machen. Hinzu kommt, dass es sich in komplexen Infrastrukturen selten um ein System handelt, sondern um viele miteinander gekoppelte Systeme, die jeweils ihre eigenen Mechanismen zur Fehler- und Redundanzerkennung besitzen. Genau dort entstehen oft die schwersten Fehlerbilder.Weder beim BMV noch in der Führung der Deutschen Bahn konnte ich bislang erkennen, dass man bereit ist, die Konsequenzen daraus zu ziehen.

Wer KRITIS sein will, muss auch bereit sein, KRITIS zu finanzieren. Das bedeutet, Resilienz, Redundanz, Personal, Wartung und Sicherheitsreserven nicht als Kostenfaktor, sondern als Teil des öffentlichen Auftrags zu verstehen.Das eigentliche Problem ist deshalb nicht dieser einzelne Vorfall oder die konkrete Architektur von GSM-R. Das Problem ist strukturell – sowohl in der Politik als auch im Konzern und damit auch bei uns Bürgern - angefangen bei den Nimbys. Jahrzehntelang lautete die Maxime: schneller, billiger und effizienter. Resilienz hingegen kostet Geld und bleibt im Alltag unsichtbar, bis sie gebraucht wird.

Genau deshalb wurde sie immer wieder zurückgestellt. Dieser Ansatz wird dem gesellschaftlichen und sicherheitspolitischen Auftrag der Eisenbahninfrastruktur nicht gerecht. Dabei wäre es letztlich zweitrangig, ob die DB InfraGO als bundeseigene AG oder in einer anderen Organisationsform geführt wird. Entscheidend ist, dass eine Gesellschaftsform (auch gemeinwohlorientiert), die primär betriebswirtschaftliche Effizienz belohnt, strukturell dazu neigt, Resilienz gegenüber kurzfristigen Einsparungen nachrangig zu behandeln. Für Kritische Infrastruktur sollte jedoch Versorgungssicherheit und Robustheit Vorrang vor maximaler Kosteneffizienz haben.

Kommtar stammt aus meinen (nicht bahnspezifischen) beruflichen Beobachtungen, da ich bei genau solchen Fällen zum Einsatz komme, wenn die üblichen Prozesse den Fehler nicht finden können und intern meist schon 24h oder gar Tage länger das Blame-Game gespielt wird.

 

[xone92]

Meiner Einschätzung nach ist sich das BMV – insbesondere in den Jahren unter CSU-Führung, aber auch schon zuvor in den 1990er Jahren – ebenso wie die Konzernspitze der Deutschen Bahn und die Leitungen der Geschäftsfelder nicht ausreichend bewusst, was es bedeutet, Betreiber Kritischer Infrastruktur (KRITIS) zu sein.Der permanente Kostendruck innerhalb des Konzerns, der maßgeblich durch die politischen Vorgaben des BMV geprägt wurde, trägt jedenfalls nicht dazu bei, eine wirklich resiliente Infrastruktur zu betreiben.

Leider wahr, durch politische Vorgaben wurde die Bahn kaputtgespart...

Kommtar stammt aus meinen (nicht bahnspezifischen) beruflichen Beobachtungen, da ich bei genau solchen Fällen zum Einsatz komme, wenn die üblichen Prozesse den Fehler nicht finden können und intern meist schon 24h oder gar Tage länger das Blame-Game gespielt wird.

Danke, du sprichst mir aus dem Herzen. Mir kommt das alles sehr sehr bekannt vor...

 

[Sierra1505]

Nein, die haben damit genau 0,000000% zu tun gehabt. Die Welt(?) hat das vor ein paar Tagen falsch kund getan und Rechenzentren haben die auch nicht. Die sind seit bald 10 Jahren Cloudfirst. Stand mal bei Heise.

Okay ich hatte 2014 mit diesem Konzern-Konglomerat zutun.

Die DB Systel ist aber der Zentrale bzw. der maßgebliche IT-Infrastruktur-Betreiber und soweit ich das aus deren DB-Internetpräsenz erlesen kann der Cloud-Services-Owner an der Stelle.
Hat aber mit diesem Problem höchstens bei einem planlosen Ticket-Forwarding durch den heiligen DB-IT-Kosmos etwas zutun. Und das kann ich mir wiederum bei der Bahn sehr gut vorstellen.

Insofern die Isolierung der GSM-Störung jedoch direkt bei der DBInfraGO abgehandelt wurde, wäre das ja sogar gut.
Aber meine Kritik richtete sicht nicht an die Lösung der Störung sonder an die Entstehung von solch tiefsitzenden strukturellen Missständen, bezogen auf kritische Infrastrukturen innerhalb einer produktiven Umgebung.
Die Meldungen da wäre dieser eine Switch bei dem der Kalt-Geräte-Stecker schon beim bloßen angucken vor sich hin knistert und man dürfe nicht die Firmware von Anno-Knips aktualisieren sonst ist im ganzen Laden das Licht aus, lesen sich wie eine Satire-Lektüre.

 

[conf_t]

Die Meldungen da wäre dieser eine Switch bei dem der Kalt-Geräte-Stecker schon beim bloßen angucken vor sich hin knistert und man dürfe nicht die Firmware von Anno-Knips aktualisieren sonst ist im ganzen Laden das Licht aus, lesen sich wie eine Satire-Lektüre.

Das ist eigentliche typisch für IT Projekte unter BWL KPIs: Zielerreichung 80% reicht. Rest nacht "Linie" - wer auch immer diese ominöse "Linie" ist und ob die davon auch weiß. Aber so passiert es (unabhängig von dem Konkreten Fall), dass im Jahr 2025 noch Cabletron, Enterasys Intellipop, Enterasys / Extreme Networks AH2 oder Cisco 3550 oder C4500 mit IOS kompiliert 2002 in Unternehmen neben moderner Netzwerkinfrastruktur ihr Unwesen treiben.

Meine Kritik an der Bahn wurde ich ja schon los. Wiederholen werde ich sie nicht.

 

[cyberpirate]

Hättest du dir mal die Mühe gemacht mehr als Headlines zu lesen wüsstest du, dass es natürlich eine Redundanz gibt und alle die täglich mit redundanten Systemen arbeiten, .........

Danke für die ausführliche Erklärung!

 

[luckysh0t]

Wenn sie erst prüfen müssten ob es einen Angriff gab, würden sie nicht erwähnen das der Failover nicht funktioniert hat.

Dass ein Failover nicht funktioniert, kann auch ein Resultat eines Angriffs sein und muss dahingehend dann geprüft werden. In einem Artikel von NTV wurde gesagt, dass der Failover manuell ausgeführt wird - nach Prüfung dessen, ob ein Angriff etc. der Schuldige ist - daher auch kein automatischer Failover.
Wenn dann der Failover nicht greift, geht die Prüfung weiter..alles zeitfressend.

Allerdings war der Artikel relativ zeitnah, kann also sein, dass diese Informationen auch obsolet sind.

 

[eYc]

Ich kann mich an einen Artikel erinnern wo berichtet wurde das in den ICE‘s Systeme mit Win3.11 laufen und das man „Experten“ sucht um diese System zu warten….wo war er denn nur gleich….

Genau passend zu dem Thema: Digitalisierung in Deutschland läuft
Maxi Gstettenbauer zum Crowdstrike-Computerausfall 2024 und dem Vorteil veralteter Software und Betriebssysteme - bei der Bahn.

 

[aid0nex]

Deswegen braucht man ein vernünftiges Change Management.

 

[conf_t]

Ja, nur sind die Behebungfristen durch die Unternehmensgovernance gerne so klein, dass man keine gescheiten Tests fahren kann sondern alles praktisch als Rolling Release durchreicht. Da hilft auch das beste Changemanagement nichts. Das ist meist gut etabliert. Nur Verstöße gegen Governanvevorgben werden gerne disziplinarisch geahndet, als denkt sich der Arbeitnehmner „Augen zu und durch“ und das Beste hoffen, da die Risiken persönlichen disziplinarischen Risiken meist größer sind als die Konsquenzen aus fehlgeschlagenen Updates. Ist ja auch praktisch: lässt sich nach außen als Automaisiertes PSM deklarieren.

Spätestens bei Unternehmenskritischen Verfahren, an denen eine 2-3 stellige Anzahl an IT Komponenten beteiligt ist, die jeweils eine unzählige Anzahl an Modulen und Bibiliotheken und Binaries haben, die jede für sich gemaintaint werden, da kann man schon ne Kleinigkeit alles zum Stehen bringen.

Große Konzerne haben gern mal ne 3-4 stellige Anzahl an UKV.

 

[Hammelkoppter]

In Unternehmen dieser Größe und Kritikalität sollte man sich Gedanken über eine Testumgebung machen. Diese kann man dann ausgiebig bei geplanten Changes entsprechendem Testkatalog nutzen.an kann eine solche Umgebung teilweise auch mieten.

Das Beheben von Schwachstellen ist ne andere Sache. Bei Schwachstellen mit hohem CVSS die auch wirklich auf meine Umgebung passen kann es durchaus schon sein, dass es schnell behoben werden muss. Dafür gibt es dann ECABs und es muss halt eine entsprechende Risikobewertung durchgeführt werden.