Webdesign, Tutorials und mehr - Webmasterpro.de

Schutz vor bösartigem FTP

Carsten Braun, am Montag den 13.12.2010 um 23:08:00

Wenn ich mir als Admin einen Keylogger einfange, habe ich ein Problem.

Ich hatte in diesem Jahr Hijacks. Ich vermutete anfangs einen eingefangenen Keylogger - den keiner von 4 Virenscannern fand. Ergebnis: überschriebene htaccess Files.

Da das immer passieren kann, denk ich immer noch über eine optimale Lösung nach. Für dieses ewige »dann hast du eben Pech« habe ich kein Verständnis und suche eine Lösung für das Problem. Es ist keine Erscheinung einer Traumwelt, sondern durchaus real.

Eine Möglichkeit ist, in die IP-Whitelist für ftp/ssh direkt einzutragen, wer nun alles über diese Protokolle Zugriff hat. Das erfordert jedoch Zugriff auf die IP-tables (den ich nicht hatte und viele andere Website-Betreiber sicher auch nicht haben).

Ich möchte anmerken, dass es weder um Root- noch um V-Server geht. Dort kann man "incrone" und andere Späße laufen lassen bzw. eine vernünftige Config zusammenbauen. Die meisten Probleme ergeben sich genau aus diesem Multikram. Und einige Hoster sind auch noch schlampig im Umgang mit Konto-Daten (siehe unten im OT)

Ich ziele auf Server ab, derer Mieter sich in der untersten Preisklasse befinden. Der Hoster wird auch wenig Ambitionen haben, eine Einzelperson aus diesem Pool, zum gleichen Preis, individuell zu betreuen.

Was wäre mit serverseitiger Kontrolle?
Server 1 connected in regelmäßigen Abständen zu Server 2 und vergleicht die Prüfsumme aller Daten auf Server 2 mit einem Sollwert, der auf einem unabhängigen dritten Server liegt.
Der Gedanke ist, dass, wenn ich wirklich einen Keylogger habe und jemand dadurch Zugriff bekommt, sich zumindest die Websites bei Manipulation gegenseitig schließen. Damit wäre es dezentral.

Im Falle einer Kompromittierung könnte man das dann soweit treiben, dass der Server, der kompromittiert wurde, mit 2 Dateien gesperrt wird: eine neue, saubere htaccess und eine neue saubere htpwd. Beide werden durch den Prüfer angelegt. Damit wäre die Seite, bis sich jemand darum kümmert, nicht mehr erreichbar; inklusive aller Subdomains. Ein Forwarding auf eine exploidete Seite (wie in meinem Falle), geht dann nicht mehr.

Der Angreifer hatte auf alle Requests an den Server einen Forward in die htaccess eingetragen und diese an zwei stellen platziert: oberhalb des public_html und im public_html - und damit auch eine Änderung der Checksumme vorgenommen. Ein unabhängiger Prüfer würde das jetzt merken - der kompromittierte Server hingegen nicht.

»Ich biete dir an, dass du mir ssh-Zugriff auf deinen Server gibst und ich in regelmäßigen Abständen deine Checksumme prüfe.«

Alles was man austauschen müsste, wären ja die pub-keys.
Damit könnte ich einer unabhängigen vertrauenswürdigen Person, oder einem anderen Server aus den eigenen Reihen, den entsprechenden RSA-Schlüssel und Sollwert geben, um mein System zu überprüfen. Oder sehe ich das falsch?

Das Hauptproblem ist ja, dass, wenn ich, zwar in regelmäßigen Abständen, jedoch lokal, eine Shell laufen lasse, welche die Prüfsumme misst, auch das auszuführende Script überschrieben oder gelöscht werden kann. Damit dummt dann mein eigenes System herum.

Man kann sich die tollsten Sachen ausdenken. Alle taugen nichts, wenn jemand auf den Server kommt.

Welche Probleme könnten sich aus so einem solchen "Bot-Net" ergeben? Welche Probleme seht ihr in diesem Verfahren? Gegenvorschläge?

Ich bitte um Feedback und weitere Ideen zur Lösung des Problems - ohne im Besitz eines Root-/V-Servers zu sein.

OT:

Ich habe die Erfahrung machen müssen, dass mein Hoster sich ziemlich vorschlagsresistent nach dem Angriff verhielt.

Vorschlag: er möge meine IPs auf eine Whitelist setzen, da ich definitiv nicht von einem gekaperten Server aus Stockholm connecte.

Man trifft auf ganz unterschiedliche Hoster. Als Beispiel ein anderes Ticket. Gleicher Hoster. Aber dieses Ticket (halbes Jahr nach dem Angriff) schaffte es in die Hall of Fame 2010:

Nach diesem Ticket, wusste ich auch nicht mehr, ob ich den Hijack nun bei mir suchen soll oder ob nicht vielleicht ein anderer auch auf die Idee kam, sich mal eine While zusammen zu schrauben... auf diese Frage werde ich keine Antwort finden.

Was übrig bleibt sind ein ungutes Bauchgefühl bei jedem Zugriff auf den Server und die Suche nach einer Möglichkeit zu verhindern, dass die Website-Besucher nicht auf exploidete Websites weitergleitet werden.

Denn das ist viel schlimmer: Ein Image kann ich schnell zurückschreiben. Aber ein Besucher, der sich gerade durch meine Website MW installiert, wird sich von mir seinen ersten Eindruck bereits gemacht haben.

Im Moment behelfe ich mir damit, dass jedes Konto eine Verknüpfung hat (sftp als auch ssh) und ich keine Passwörter/Benutzernamen tippen muss.

Vielen Dank für eure Zeit.

PS: Ich bin kein Admin, sondern Grafiker mit Webserver.

christian, am Mittwoch den 15.12.2010 um 00:57:00

Für meine Aufmerksamkeitsspanne war der Text grad etwas viel aber hier mal meine Gedanken:

Das sicherste ist wohl eine Live-CD zu benutzen. Bleibt jedoch noch die unverschlüsselte Übertragung. Wenn dein Netzwerk kein WLAN hat bist du relativ sicher (am Besten alle anderen Rechner zu dem Zeitpunkt auslassen). Am besten wäre es allerdings die Verbindung zu verschlüsseln (FTP über TLS oder SFTP) , das ist allerdings bei einfachem Webspace meistens nicht ohne weiteres möglich.

Verbindungen von öffentlichen Netzwerken meiden (wenn unverschlüsselt).

Ich persönlich würde aber solche Vorkehrungen allenfalls für Online-Banking treffen. Ich frag mich immer wie man an so Sachen wie Keylogger kommt ohne auf irgendwelchen Zwielichtigen Seiten zu surfen oder mit "Warez" zu hantieren und selbst wenn man das tut sind die Chancen bei installiertem Viren-Scanner sehr gering (Heuristische Suche vorausgesetzt), denn Keylogger-Verhalten lässt sich ziemlich einfach erkennen. (außer du benutzt ne drahtlose Tastatur und jemand im Nachbarzimmer fängt das Signal ab, da könntest du versuchen das Zimmer mit Alu-Folie zu tapezieren)