Zugegeben: Wir arbeiten zwar in einem gehobenen Hosting-Segment, allerdings nicht im Enterprise- oder Hochsicherheitsbereich. Und schließlich geht es hier um Maschinen, die zwar unserer Kontrolle unterstehen, die aber nicht uns gehören, so dass letztlich der Kundenwunsch den Ausschlag gibt, was zu tun ist. Im konkreten Fall ging es um eine Maschine, deren root-Zugang kompromittiert wurde. Das ist extrem selten, immerhin pflegen wir die unserer Betreuung unterstehenden Maschinen gut, so dass Sicherheitslücken in als root laufenden Diensten so gut wie nie zum Tragen kommen, bevor das Update eingespielt ist – aber „so gut wie nie“ ist eben nicht „nie“.
Dem Kundenwunsch entsprechend sollte die Maschine allerdings nicht vollständig geplättet und neu aufgesetzt werden, sondern (nach Schließung der Sicherheitslücke) lediglich gesäubert werden. Das ist an sich auch unproblematisch, da wir Prüfsummen aller ausführbaren Programme erstellen und somit Kompromittierungen im Allgemeinen gut erkennen können, sofern sie nicht so weit gehen, dass Kernelmodule installiert werden, die ein Rootkit vollständig verbergen. Wir kennen in einem solchen Fall aber letztlich auch unsere Grenzen, sprich, wir sind Webhoster und keine Security-Leute. Dieses Feld überlassen wir lieber Leuten, die sich damit auskennen, so wie wir uns in unseren Dingen gut auskennen. Nun, wie gesagt, die Maschine wurde nach Kundenwunsch und nach unserem besten Wissen und Gewissen gesäubert und ging kurz darauf wieder in Betrieb.
Warum dann allerdings die Maschine wenige Tage später erneut kompromittiert wurde, war uns zunächst ein Rätsel, zumal sich an der installierten Software keine Lücken mehr zeigten.
Die Lösung: Bei der vorherigen Kompromittierung hatten die Angreifer dem Systemuser games ein Passwort gegeben – und sich ganz trivial eingeloggt. Und aus eben diesem Grund sollte man Maschinen nach einer root-Kompromittierung im Regelfall immer plätten: Es ist praktisch ausgeschlossen, alles zu finden, was ein Angreifer installiert hat, egal wie gewissenhaft man vorgeht. Zugegeben: Ein Passwort auf einem User, der normalerweise keins hat (und damit auch keinen Login), war erschreckend trivial. Wir schämen uns – und setzen’s auf unsere Liste von Dingen, die nach einer root-Kompromittierung zu prüfen sind, sollte ein Neuaufsetzen der Maschine keine Option sein.