Kleine Geschichten der IT-Unsicherheit

Sicherheit bei IT-Systemen ist so eine Sache: Nach über 20 Jahren im Berufsleben haben sich eine Menge Geschichten bei mir angesammelt, darunter eben auch viele, die sich mehr oder weniger um das Thema IT-Sicherheit drehen. Und möglicherweise kann man aus der einen oder anderen Geschichte noch ein wenig was lernen.

Ordnung und Dokumentation

Auch das gehört zum Thema Sicherheit: Dokumentation und Ordnung. Es ist tatsächlich nicht nur bei kleineren Unternehmen oder Privatleuten so, dass Systeme erst einmal aufgebaut werden und man die Dokumentation dann auf „später“ verschiebt. Dieses „später“ wird dann auch ganz gerne mal immer weiter in die Zukunft geschoben. Und wenn man dann die Dokumentation bräuchte, dann ist sie eben noch nicht da. So gab es einen Fall bei einem größeren IT-Dienstleister, der für einen Kunden einen nicht ganz kleinen Cluster betrieben hat. Oder eben betreiben sollte. Der lief auch nach den Tests gut und so wurde er in den Produktivbetrieb genommen, die nur teilweise erfolgte Dokumentation sollte dann während dieses Produktivbetriebs vervollständigt werden.

Dummerweise lief das Ding aber nach zwei Tagen nicht mehr. Die Fehlersuche dauerte eine knappe Woche, aber gefunden wurde der Fehler erst, als jemand auf die Idee kam, doch mal alle Kabel nachzuverfolgen. Ich war nicht selbst im Rechenzentrum als der Fehler gefunden wurde, aber aus erster Hand wurde mir die Situation geschildert, in der ein Techniker sich dachte, dass ein Kabel wohl falsch stecken würde und es einfach mal testhalber umgesteckt hat. Und plötzlich lief das Ding wieder. Gut, wäre die Dokumentation fertig gewesen und wären auch alle Kabel sauber beschriftet gewesen, dann wäre die Sache viel schneller zu lösen gewesen, nämlich direkt nach dem Ausfall: Da hätte der andere Techniker, der das Kabel durch Drüberstolpern heraus gezogen hatte, es direkt richtig wieder anschließen können, statt es einfach mal in die nächste, mechanisch passende Dose zu stecken.

Zugegeben: Dokumentationen sind die unangenehmste Aufgabe im IT-Bereich und niemand dokumentiert gerne irgendwelche Systeme, vor allem, weil man ja immer denkt, man könne doch jederzeit nachvollziehen, was man da gebaut hat. Stimmt aber nicht. Wenn man ein System nur lange genug nicht mehr „angefasst“ hat, weil es eben einfach läuft, dann steht man irgendwann selbst vor dem, was man da gebaut hat und fragt sich, was man da gebaut hat und warum.

Noch schlimmer ist es nur, wenn man Systeme übernimmt, für die es keine Dokumentation gibt. Das ist mir in den letzten Jahren mehr als einmal passiert, das reichte von einem WordPress-Theme bis hin zu den kompletten Systemen zur Abrechnung und Verwaltung in einem Unternehmen, bei dem dann die „Dokumentation“ aus einer Passwortliste für 12 der 17 Server bestand, auf der drei verschiedene Passwörter mehr oder weniger zufällig für die unterschiedlichen Systeme verwendet wurden. Gut, die Passwörter für die fünf verbliebenen Server hatte ich dann schnell raus, mehr als drei musste ich ja nicht probieren.

Schulung

Auch das Thema Schulung ist so ein Ding. Egal ob im privaten Bereich oder im geschäftlichen Umfeld, ohne ein Minimum an Schulung geht es einfach nicht. Dabei sollte man immer berücksichtigen, wer alles in Berührung mit einem System kommt und zumindest die elementarsten, für sie relevanten Infos sollte man diesen Leute geben. Egal ob man nun den Eltern einen neuen Router aufstellt oder für ein Büro einen Fileserver.

Für einen Kunden hatte ich mal einen Filserver für sein Büro aufgebaut und installiert. Mangels eigenem Serverraum, wurde dieser an einem unbenutzten Schreibtisch neben der Eingangstür aufgestellt, den Aufbau hat der Kunde selbst gemacht, war ja kein großes Ding. Er hat von mir dann eine kurze Einführung, eine dreiseitige Dokumentation des für ihn relevanten Webinterfaces (Verwalten der User, Runterfahren der Maschine usw.) und einen Infotext für die Nutzer, wie die sich anmelden können bekommen. Eigentlich alles gut, oder?

Zumindest so lange, bie der Kunde sich in seiner FritzBox einen VPN-Zugang eingerichtet hatte und von daheim aus arbeiten wollte. Plötzlich kam der Anruf, dass der Filserver sich jeden Abend abschalten würde. Immer zwischen 19 und 20 Uhr und immer etwa 20-40 Minuten. Aber nur unter der Woche, nicht am Wochenende. Das müsse an dem Server liegen, auf jeden Fall und ich solle gefälligst den Fehler finden, weil ich den „Schrott“ ja eingerichtet habe.

Ich solle den Server abholen und ausführlich testen. Also habe ich das getan, den Server drei Tage lange komplett durchgetestet, alle Logfiles durchforstet – kein Probleme zu finden. Lange Rede, kurzer Spaß: Am Ende stellte sich heraus, dass es wirklich die Putzfrau war, die abends einfach mal den erstbesten Stecker aus der Steckdose gezogen hatte, um ihren Staubsauger dran zu hängen – da der Server an einem unbenutzten Schreibtisch neben der Eingangstür stand… Ich glaube, die Geschichte kennt in der einen oder anderen Form jeder, alleine ich selbst habe sie in den letzten 20 Jahren dreimal persönlich miterlebt.

Was lernen wir daraus: Jeder Mitarbeiter, der mit einem System in Berührung kommt, muss entsprechend geschult werden und sei es eben nur ein „Ziehe diesen Stecker niemals aus der Dose, niemals nicht!“ für die Putzkraft.

Passwörter

Das gehört an sich mit in das Thema Dokumentation und Schulung, aber Passwörter sind eine so sensible Information, die haben eine eigene Erwähnung verdient. Alleine zwei der beschrieben Fälle sind auch so Passwort-Fälle. Angefangen bei der Tatsache, dass man Passwörter nach Möglichkeit niemals mehrfach verwenden sollte, sondern man für jedes System und jeden Dienst ein eigenes Passwort nutzen sollte, gibt es dann noch das Thema „Passwort-Dokumentation“. Und in der Richtung habe ich echt schon alles gesehen, wirklich alles.

Passwortdokumentation

Angefangen bei maximal unsicheren Passwörtern („Wie ist denn das Passwort für das System?“ – „geheim“ – „Ist mir klar, aber ich muss auf das System drauf, sonst kann ich nicht arbeiten…“ – „Das Passwort ist g – e – h – e – i – m“), die offensichtlich nicht auszurotten sind, bis hin zu den kreativsten Arten, Passwörter zu speichern oder auch nicht. Der eben erwähnte Fileserver hatte übrigens einen Aufkleber vorne drauf, als ich ihn zum Check abholte. Auf diesem Aufkleber standen dann mit Textmarker hervorgehoben Username und Passwort für das Admin-Interface.

Unzählige Passwörter klebten auf Notizzetteln an der Unterseite von Tastaturen oder auch gleich ganze Passwortlisten auf dem Monitor des zugehörigen Arbeitsplatzes, alternativ wurden Passwörter auch gerne in Textdateien – natürlich barrierefrei im Klartext – gespeichert. Interessanterweise haben einige der „Passwort-auf-Notizzettel“-Fraktion die Frage, warum sie denn keinen Passwortmanager verwenden würden, mit „die sind doch unsicher“ geantwortet. Keine Pointe.

In meinem ersten Job hatte ich sogar einen Chef, der von mir verlangt hat, dass ich die root-Passwörter zu jedem Server gefälligst auf einen Zettel zu schreiben hätte, der dann auch jeweils am Server anzubringen sei. Wenn da nur das Passwort stünde, dann würde schon keiner drauf kommen, dass es das root-Passwort zu dem Server wäre. Meine Weigerung, die Passwörter auf diese Art zu dokumentieren, führte dann zu meinem ersten Rausschmiss, der aber nicht von langer Dauer war – kurz nach mir wurde eben jener Geschäftsführer ersetzt und man bat mich, doch wieder zurück zu kommen.

Passwortsharing

Das Teilen von Passwörtern ist auch so eine Unsitte, die einfach nicht totzukriegen ist, da kann man machen, was man will. „Nimm einfach schnell meinen Account“ klingt manchmal nach einer guten Idee für den Moment, aber spätestens dann, wenn ein Mitarbeiter das Unternehmen im Streit verlässt und man feststellt, dass dieser Mitarbeiter im Prinzip die Passwörter der Hälfte seiner Kollegen kennt, merkt man, dass das dann mittel- bis langfristig eher doch keine gute Idee ist. Andererseits hätte der Mitarbeiter entsprechende Daten wohl auch schon vorher aus dem Unternehmen tragen können, also ist es ja dann auch schon egal. Irgendwie zumindest.

Passwort vergessen

Ein echter Glücksfall ist für manchen Zeitgenossen ja die Tatsache, dass es heute fast überall eine Funktion gibt, um vergessene Passwörter zurückzusetzen – so lange man das Passwort für den eigenen Rechner und den Mailaccount nicht vergisst, erzeugt man sich einfach jedes Mal, wenn der gespeicherte Login abgelaufen ist, ein neues Passwort. Klingt komisch, ist aber so und sind wir doch mal ehrlich: Sicherer als die Passwörter als Liste an den Monitor zu kleben, ist dieses Vorgehen auf jeden Fall :)

Firewalls

Viele Unternehmen setzen Firewalls ein und stehen dann auf dem Standpunkt, dass jetzt alles gut wäre. Schließlich stünde da ja eine Firewall, jetzt könne also nichts mehr passieren. Aber man müsse ja unbedingt für $neusterheißerscheißinderhood noch eine Ausnahme definieren und Mitarbeiter X hat daheim nur Betriebssystem Y, könnte man da nicht statt einen VPN-Zugang einfach irgendwo einen Port für ihn aufmachen? Außerdem muss unbedingt ein Webfilter rein, der anhand von URL-Bestandteilen den Zugriff auf Webseiten blockiert, aber dazu bitte auch eine Ausnahmeliste pflegen, schließlich will man keine Seiten zulassen, in deren URL irgendwo „sex“ steht, es sei denn, sie gehören zu seriösen Webseiten. Man hat da mal eine Liste vorbereitet… Und irgendwann merkt man, dass die Geschwindigkeit des Internetzugangs absolut unterirdisch ist, egal wie dick man die Leitung aufpumpt.

Mal abgesehen davon, dass immer gewaltige Listen von Regeln in Firewalls die Performance des Systems nicht unbedingt beschleunigen, sie werden irgendwann auch extrem unübersichtlich, wenn versucht wird, jeden Spezialfall abzufangen. Mir sind schon Listen mit Firewallregeln untergekommen, bei denen versucht wurde, eine Positivliste zu pflegen, für jede einzelne Seite, auf die die Mitarbeiter Zugriff haben sollten – teilweise auch noch speziell pro Mitarbeiter. Das ist zwar einige Jahre her und das Internet war damals noch kleiner, aber es ging da um rund 125 Mitarbeiter und eine Positivliste von über 10.000 Webseiten. Ich habe nie erfahren, wer sich die Mühe gemacht hatte, diese Liste zu erstellen, wer aber auch immer das war – diese Person hat jegliches Mitleid voll und ganz verdient.

Und einen großen Nachteil haben lange und unübersichtliche Listen, egal ob es nun eine Liste von Firewall-Regeln oder irgendeine andere ist: je länger und unübersichtlicher so eine Liste wird, desto fehleranfälliger wird das System, so lange Menschen mit diesen Listen arbeiten. Da überliest man schnell mal einen Tippfehler oder übersieht eine Zeile. Und wenn es dumm läuft, hat man dann damit ein Loch in die Firewall gebohrt, von dem keiner etwas ahnt, bis es jemand findet, der es dann ausnutzt.

Gerade bei Firewalls bin ich persönlich ein Fan des KISS-Prinzips: Keep It Simple, Stupid! Man kann einfach nicht jeden irgendwie denkbaren Fall abdecken, man kann sich ja nicht mal jeden denkbaren Fall so ohne weiteres ausdenken. Geht halt nicht. Die Regeln sollten bei einer Firewall erstmal alles verbieten und dann erlaubt man eben das, was benötigt wird und ist dabei so großzügig, wie es möglich ist. Und irgendwelche Webfilter, die anhand von URL-Bestandteilen entscheiden, ob auf eine Seite zugegriffen werden darf oder nicht, halte ich in den meisten Fällen für überflüssig, vor allem in Großraumbüros.

Was anderes sind Filter, die gemeldete Seiten mit Schadsoftware blocken. Ansonsten: Man verpflichtet die Mitarbeiter dazu, sich an gewisse Regeln zu halten und hält ein Auge darauf, was da so passiert. Das sollte in den meisten Fällen wirklich ausreichen. Aber man könnte hier über die richtige Strategie natürlich lange und ausführlich streiten.

Updates

Updates sind für die Sicherheit von IT-Systemen essentiell, da hilft nichts. Man kann sicher mit dem ein oder anderen Update in bestimmten Situationen mal warten, aber es gibt ja wirklich Menschen, die glauben, dass das Motto „Never touch a running system“ auch das Installieren von Updates verbieten würde. Und was halt wirklich heftig ist: Viele kommen damit sehr lange sehr weit.

So einige Systeme wurden mir in den vergangenen Jahren übergeben, bei denen ich mich echt gefragt habe, warum da nichts passiert ist. Rekord war ein WordPress, welches über drei Jahre lang keine Updates gesehen hatte – wobei der Kunde aber trotzdem pünktlich jeden Monat für „Wartung und Pflege“ des Systems zur Kasse gebeten wurde. Ich hätte es nicht für möglich gehalten, dass ein WordPress ohne Updates so lange nicht gehackt wird, aber wenn es natürlich nur alle paar Wochen neuen Content auf so einer Website gibt, dann kann man natürlich mit tagesaktuellen Backups jeden Hack schnell ungeschehen machen und hoffen, dass er sich nicht so bald wiederholt.

An anderer Stelle erwähnte ich schon den Rootserver-Kunden, der glaubte, am Hack seines Systems sei der Provider schuld gewesen und nicht er selbst, weil er zwei Jahre lang alle vom System angebotenen Updates ignoriert hatte. Oder den Chef, der meinte, dass ein laufendes System keine Arbeit machen würde, man müsse es nur einmal installieren, dann würde es schon laufen und bräuchte keine Pflege und Wartung mehr. Mit schöner Regelmäßigkeit fragen mich Menschen um Hilfe bei ihren privaten Rechnerproblemen und genau so regelmäßig sitze ich dann vor Systemen, die regelrecht um die Installation von Updates betteln – ohne Erfolg. Das ist übrigens ein Grund, warum ich ein echter Fan automatischer Updates – zumindest was Security-Updates angeht – bin, wie sie Windows 10 macht und macOS zumindest anbietet.

Man möchte solchen Menschen ins Gesicht brüllen, warum sie so respektlos sind. Respektlos gegenüber unzähligen Entwicklern, die die Software entwickeln und Fehler ausmerzen und nicht zu vergessen die Entwickler, die diese ganzen praktischen und bequemen Update-Mechanismen gebaut haben: „Zeigt doch ein bisschen Respekt und benutzt die dann auch und installiert die Updates!“