Warum wir (und unsere Kunden) uns nicht vor dem Erpressungs-Trojaner CTB-Locker fürchten

Der genaue Weg, über den die Schadsoftware die Server befällt, ist noch nicht bekannt. Daher können wir nicht 100% sicher sein, sicher zu sein. Das ist aber kein Grund zur Besorgnis, sondern der Normalzustand in der IT.

Bezüglich CTB-Locker sehen wir keine konkrete Gefahr. Denn:

1. CTB-Locker ist auf Masse ausgerichtet. Diese Schadsoftware nutzt bekannte Sicherheitslücken in weit verbreiteter Software aus. Im heise-Artikel werden Wordpress und Joomla genannt, die schon in der Vergangenheit beliebte Angriffsziele waren. Beide (und vergleichbare Programme) haben wir auf unseren Servern nicht installiert.

Unsere Webseiten und Webanwendungen sind individuell programmierte Software. Sie werden eigene Sicherheitslücken haben, aber eben keine allgemein bekannten. Daher dürfte es für die Erpresser nicht lohnenswert erscheinen, diese heraus zu finden und gezielt dafür einen Schädling zu programmieren.

2. Um effizient zu arbeiten und robuste Lösungen zu schaffen, entwickeln aber auch wir nicht jede Komponente unserer Webanwendungen neu. Beispielsweise lieben wir das Symfony-Framework und setzen Symfony in den allermeisten Projekten ein. Symfony ist weit verbreitet - und wenn darin ein Fehler bekannt wird, könnte es theoretisch auch Ziel von Schadsoftware wie dem CTB-Locker werden.

Deshalb informieren wir uns täglich über die Sicherheitslage in der IT-Welt und haben dabei ein besonderes Augenmerk auf die von uns eingesetzte Software. So können wir rechtzeitig handeln, unsere Systeme absichern und ggf. mit betroffenen Kunden Kontakt aufnehmen. 

Generell empfehlen wir unseren Kunden regelmäßige Updates der wichtigen Komponenten. Bei aktuellen Aufträgen erledigen wir das auch gerne nebenher.

3. Da der konkret Angriffsweg des CTB-Lockers noch unbekannt ist, können wir zwar nicht konkret dazu Stellung nehmen. Aber wir können allgemein fest halten, dass wir unsere Server in der Amazon Cloud und damit in einem vernünftigen Sicherheitsrahmen hosten lassen. Die fachmännische Konfiguration unserer Server ergänzt dann den Schutz unserer Lösungen.

4. Selbst wenn so ein Schädling einmal in einen Server eindringen und dort wüten sollte - haben wir von allen wichtigen Dateien Backups, auf die der Schädling keinen Zugriff hat.

• Code speichern wir in einem komplett getrennten Repository-System, der dann während der Installation/eines Updates auf den jeweiligen Webserver kopiert wird.
• Für Datenbanken haben wir tagesaktuelle Backups, die auch mehrere Tage zurück reichen. Diese Backups werden nach ihrer Erstellung vom Server getrennt und sind für einen etwaigen Schädling nicht erreichbar.
• Binär-Dateien (wie z.B. Bilder und PDFs) speichern wir vorzugsweise in Amazons S3-System, das wiederum getrennt ist, so dass ein Schädling ebenfalls keinen Zugang dazu hätte.

Die Prozedur, Daten aus Backups wiederherzustellen, führen wir alle etwa alle 2-3 Monate aus, wenn ein Kunde versehentlich seine Daten gelöscht hat und sie weiderhergestellt haben möchte. Daher haben wir darin eine gewisse Routine darin und können unsere Schritt-für-Schritt-Anleitung dafür aktuell halten. Eine solche Anleitung ist wichtig, damit man in einer solchen Stress-Situation nichts mehr falsch machen und die Daten schnellstmöglich wiederherstellen kann.

Insofern – bleiben wir wachsam, sehen aber keine aktuelle Gefahr durch CTB-Locker. Und selbst wenn er oder ein anderer Schädling es einmal schaffen sollte, in unsere Server einzudringen und dort wichtige Dateien zu verschlüsseln oder löschen - sind wir auch darauf vorbereitet. Helms Klamm hatte ja auch nicht nur eine Mauer.