Letztes Wochenende bekam ich eine E-Mail, die mir zunächst dubios vorkam; eine abuse-Meldung eines anderen Providers. Also eine Beschwerdemail, dass von meinem Server aus Aktivitäten erfolgen, die die Sicherheit oder die Funktionsfähigkeit der Server des anderen Providers oder dessen Kunden beeinträchtigen können. Ich sah mir die Mail noch mal genau an und stellte fest, dass es sich bei der erwähnten IP-Adresse tatsächlich um die meines Servers handelt. Ich wurde unruhig und loggte mich auf dem Server ein und sah, dass sowohl die Prozessoren als auch das Netzwerk komplett ausgelastet waren. Irgendetwas stimmte also tatsächlich nicht.
Ein kurzer Blick mit htop, zeigte mir die Ursache. Etliche Prozesse liefen mit Vollast. und feuerten wohl fleißigauf diverse Ziele im Internet. Erste Maßnahme: Netzwerk mit if-down eth0 deaktivieren. Dann komme ich zwar selbst nicht mehr mit SSH rauf, aber ich kann über die Konsole des Providers meinen Server erreichen.
Die ganzen Prozesse liefen unter einem einzigen Benutzeraccount. Dieser Account hat zum Glück nur einfache Rechte. Aber er konnte im /tmp-Verzeichnis seine Scripte platzieren.
Dann ging die Ursachenforschung los. In den Log-Dateien konnte ich tatsächlich feststellen, dass mit Brute-Force (also massiven Ausprobieren) mit unterschiedlichen Nutzernamen und Passwörter versucht wurde, per SSH in das System einzudringen.Zwischen 3 und 4 Uhr hat es dann geklappt. Der Angreifer war auf meinem Server. Ich kann nicht genau feststellen, wann was passiert ist, aber auffällig war, das die Scripte nicht dauerhaft liefen. Es gab ein paar Stunden Pause. Vielleicht hat sich in der Zwischenzeit ja tatsächlich der Hacker mal persönlich umgeschaut, was er so mit dem Server anstellen kann. Ich weiß also nicht, was manuell passierte und was durch Scripte.
Er hat einen Cronjob erstellt, der beim Reboot und zu bestimmten Zeiten unterschiedliche Aktivitäten ausgelöst wurden. So wurde etwasder Schadcode jedes Mal von einem fremden Server neu geladen, auch wenn das /tmp-Verzeichnis geleert wurde. Im User-Verzeichnis fanden sich ein paar neue Verzeichnisse die die kleinen Skripte enthielten. Insgesamt waren das nur ein paar Megabyte. Dann habe ich noch festgestellt, dass sich der Angreifer einen SSH-Key erstellt hat, um damit auf den Server zu kommen. Ein einfache Ändern des Passwortes hätte nicht ausgereicht, er wäre durch den Schlüssel auch dann wieder rein gekommen.
Deshalb habe ich nicht nur alle Passwörter geändert, sondern auch die SSH-Keys gelöscht, bzw. meine eigenen neu erstellt.
Nach einer kurze Analyse kam ich zu dem Schluss, dass sich der Angreifer nur im Umfeld des Benutzeraccounts aufgehalten hat und keine erweiterten Rechte erlangen konnte. Auslesen konnte er dann mangels Rechte auch keine anderen sensiblen Daten.
Aber wie konnte es überhaupt dazu kommen? Ich hatte einen Benutzer für interne Zwecke erstellt. Leider habe ich diesem nur ein schwache Passwort gegeben. Wenn SSH aktiviert ist und nicht entsprechend konfiguriert ist, erhält dann jeder Benutzer die Möglichkeit per SSH anzumelden. Das war mir nicht bewusst. Nun habe ich in der /etc/ssh/sshd_conf einfach mit dem Schlüssel AllowUsers die Benutzer angegeben, die auch tatsächlich diesen Zugang haben sollen.
Ich hatte fail2ban zwar installiert, welches eigentlich solche Brute-Force-Angriffe abwehren sollte, aber irgendwie funktionierte es nicht. Ich vermute, dass ich mir bei einem Debian-Update wohl die Konfig zerschossen wurde. Ich werde jetzt in Zukunft ein Auge darauf haben.
Zusätzlich habe ich den Port des SSH-Dienstes verstellt. Ich weiß das ist kein Sicherheitskonzept, aber zumindest erschwert es den unbefugten Zugang.
Der Server scheint jetzt wieder sauber zu sein und läuft seit mehreren Tagen unauffällig.
Ich frage mich allerdings, was gewesen wäre, wenn das nicht gerade am Wochenende passiert wäre, als ich zu Hause war und Zeit hatte, mich darum zu kümmern. Irgendwann hätte der Provider den Server abgeschaltet und ich hätte dort wahrscheinlich so schnell keinen neuen Server bekommen.