SFTP als Schutz gegen Netzwerk-Sniffer

Kürzlich wurde der Server eines Kunden gehackt. Eine richtig unangenehme Sache, auch wenn das Ganze innerhalb einer Stunde behoben war. Die Fragen dieses Artikels: Wie ist der Hacker eingedrungen und wie kann man sich gegen diesen Angriff schützen?

Aufmerksam wurde ich auf das Geschehen dadurch, dass der Kunde durch eine Klientin darauf hingewiesen wurde, dass sie nach dem Besuch einer seiner Webseiten einen Trojaner auf ihrem Rechner gefunden hatte. Ich besuchte die Seite und fand tatsächlich im Footer ellenlangen verschlüsselten Code. Weitere Suche zeigte, dass fast alle Dateien mit Namen wie index.html, index.php etc. auf dem Managed Server bei 1&1 nun Schadcode enthielten.

Ein Anruf beim „Platin Support“ von 1&1 verlief zäh. Der Supporter wollte nicht wirklich helfen, im Hintergrund hörte ich die Stimme seines Kollegen, der ihm immer wieder die Antworten auf meine Fragen vorflüsterte. Ein Blick in das FTP-Log des fraglichen Zeitpunktes zeigte, dass die Dateien alle per FTP verändert worden waren. Circa einhundert Dateien im Verlauf einer Stunde, jede Datei von einer anderen IP-Adresse aus. Soviel zum Thema Automatisierung…

Klar war, dass der Hacker über FTP reingekommen war. Hatte er das Passwort „erraten“?  Der verwendete FTP-Zugang war nicht der meine gewesen, sondern der, den ein 3er-Team von Programmierern verwendet hatte. Ich informierte alle. Deren Rechner waren sauber. Doch dann stellte sich heraus, wie es wohl gelaufen war:

Ein Verwandter eines der drei Progger hat seinen Rechner im selben Netzwerk hängen. Er war im Internet gesurft und hatte sich durch den Besuch einer infizierten Website einen Trojaner auf den Rechner geholt. Dieser nutzte dann einen Netzwerk-Sniffer, um den Netzwerk-Verkehr abzuhorchen. Als der Programmierer dann auf dem Server Dateien per FTP hochlud, fing der Sniffer das im Klartext übermittelte Passwort ab und übermittelte es an einen Host. Danach – schätze ich – wurden automatisiert kontrollierte Rechner mit der Infektion des Servers beauftragt. Die infizierten Webseiten sollten dann weitere Rechner von Surfern infizieren usw. Dasselbe Spiel wieder von vorn.

Insofern hätte dieser Hack relativ einfach verhindert werden können: Indem der Programmierer statt FTP das sogenannte Secure File Transfer Protocol (SFTP) verwendet hätte. Hierbei wird eine ansonsten ungesicherte File-Transfer-Protocol-Verbindung (FTP) teilweise über Secure Shell (SSH) getunnelt. Somit werden die Login-Daten durch einen verschlüsselten SSH-Tunnel übertragen – der Sniffer hätte keine Klartext-Passwörter abfangen können. Unverschlüsselt geschieht lediglich der eigentliche Datentransfer, dessen Port zwischen Client und Server zufällig ausgehandelt wird.

Leider unterstützen noch nicht alle Provider dieses Verfahren. Unter den Großen konnte ich aber fast alle finden. Allerdings unterscheiden sich die Einstellungen:

• 1und1: SFTP, ganz problemlos.
• Strato: Hier war die Lösung am Schwersten zu finden. Man muss erst ein Masterpasswort vergeben (im Kundenbereich unter dem jeweiligen Paket > Einstellungen > Passwörter festlegen). Danach soll man sich einloggen können per SFTP mit den Angaben: Port 22 (wie üblich), Hostname: ssh.strato.de, User Name: www.domain.de, Passwort: Masterpasswort. Dummerweise funktioniert auch dies bislang nicht – ich bin noch mit dem Support in Kontakt.
• HostEurope: Nutzt FTPES (FTP über explizites TLS/SSL).
• all-inkl.de: Klappte mit SFTP nicht, aber mit FTPES.
• Domainfactory: Funktioniert sowohl mit SFTP als auch FTPES.

Bei diesen fünf Providern konzentrieren sich alle meine Kunden. Insofern lässt sich hier – mit Ausnahme von Strato bislang – alles gut absichern. Bei einigen kleinen Providern aus meinem Portfolio funktionierte es weder mit SFTP noch mit FTPES in den Standardeinstellungen. Hier hoffe ich, dass nachgebessert wird. Und empfehle jedem: Verwendet nach Möglichkeit kein FTP!!! Bei Filezilla lässt es sich leicht einstellen bei jedem eingetragenen Server: Servermanager > Allgemein > Einstellungen > ServerType.

Einen Vorwurf kann ich dem Mitarbeiter nicht machen: SFTP wurde noch nicht unterstützt, als er damals sein FTP-Programm eingerichtet hat, und während sein Firmennetzwerk sauber ist, konnte er nicht ahnen, dass ein kleiner Änderungsversuch von zu Hause aus diese Folgen haben könnte. Aber jetzt wissen alle Bescheid…

Ach ja, und hier noch ein  Security-Posting der letzten Tage über weitere infizierte Sites.