Attacke auf Webserver

H

hagim

New Member
Hi

Ich bin gerade neu hier, also zuerst mal an Hallo an alle ;)

Ich brauche wahnsinnig dringend Hilfe, denn auf meinem Webserver ist gestern etwas sehr bedenkliches passiert, und ich hab ehrlich gesagt keine Ahnung, wie das geschehen konnte, bzw. wie ich das ganze einschränken soll.

Ich hoste auf einem Debian Lenny mit Apache 2.2.9 und diversen Modulen (PHP, Perl, Tomcat, ..) ca. 200 Webseiten.
Als FTP-Server verwende ich Proftp.
Aufgesetzt wurde das ganze nach Anleitung von Howtoforge (http://www.howtoforge.de/howto/der-perfekte-server-debian-lenny-debian-50-ispconfig-2/)

Der Server läuft seit ca. einem Jahr einwandfrei.

Doch letzte Nacht geschah das unfassbare:

In sämtlichen Startseiten aller gehosteten Webseites wurde ganz unten im Code ein DIV-Element platziert mit einem Link zu irgendwelchen Pornoseiten.
Das Div wird per visibility:hidden versteckt.

Sieht ca. so aus:

HTML: 
<div style="overflow:auto; visibility:hidden; height: 3px; "><ul> <a href="http://url.zu.einer.blogseite.mit.pornobildern/">anstössiges wort</a> </ul></div>

Wie kann so etwas passieren??
In den FTP und SSH-Logs finde ich nichts verdächtiges...
Sehr merkwürdig dabei ist, dass bei den verändereten index-Seiten auf dem Filesystem das Modifed-Datum nicht verändert wurde.

Habe das System bereits mit chkrootkit und rkhunter abgesucht...dabei kam nichts verdächtiges zum Vorschein.

Bin für jeden Tipp dankbar... :confused:
 
Hallo

rkhunter etc. bringt bei einem kompromittierten System meistens herzlich wenig.

Was für Webseiten hostest du? Bzw. verwenden die Webseite ein bekanntes CMS oder sonstiges? Sind alle Scripte etc. auf dem neusten Stand?
 
Und der ProFTP und die anderen Programme waren auch alle auf dem aktuellen Stand? Die Logdateien geben nix her?

Das div wurde auf der Webseite also gar nicht angezeigt?
 
Du kommst nicht darum herum, den Server neu aufzusetzen. Vorher Logs auswerten und Lücke finden - anschließend Server neu aufsetzen ohne die Lücke. Einem kompromittiertem System kannst du nicht mehr vertrauen - das der Server kompromittiert ist, erkennst du daran, dass in jeder Webseite ein Code hinzugefügt wurde.
 
Hi

Es handelt sich dabei um Verschiedene CMS-Systeme.
Eines ist Weblication CMS 4.x, aber auch Typo3-Systeme sind betroffen.
Es sind aber auch Seiten betroffen, die gar kein CMS dahinter haben...

Muss ich davon ausgehen, dass der Server gerootet wurde und die Änderungen "auf dem System" selbst gemacht wurde, oder gibt es bekannte Verfahren, wie solches "Content manipulieren" über den Apachen oder FTP oder so gemacht wurden?
Was kann es zu bedeuten haben, wenn die veränderten Dateien auf dem Filesystem gar nicht als Modified gekennzeichnet sind?

Hast du mir irgend einen Tipp wie ich nun vorgehen soll?

Freundliche Grüsse und vielen Dank für die Samstagabendliche Hilfestellung ;)
 
Ich hatte dazu schon mal was geschrieben im Forum unter:

kompromittierter Server?

Hi, auch ich habe heute von Strato einen Hinweis bezüglich meines V-Servers bekommen: Ihr Server blabla.stratoserver.net hat in den letzten Stunden in unserem Monitoring ein auffälliges Verhalten aufgewiesen. Wir vermuten daher, dass Ihr Server kompromittiert ist. Aha. Naja. Dann...
serversupportforum.de serversupportforum.de

Zusätzlich ist es natürlich nicht ausgeschlossen, dass ein Rootkit installiert worden ist.

Bitte überprüfe auch noch die access.logs nach RFI oder MySql injections.

Oft wird auch gerne ein Cronjob unter dem Webserver User (z.B. bei Apache(2) www-data) angelegt, der regelmäßig eine Backdoor öffnet.

Ich würde aus der Erfahrung sagen, dass es sich um ein RFI gehandelt hat und dann via PHP-Shell (z.B. c99) alle index.php Dateien infiziert wurden. Die "neuen" PHP-Shells haben diese Funktionalität schon implementiert. Man muss nur noch den Schadcode eingeben und der wird dann verteilt.

Daher bitte die access.logs nach RFI durchsuchen und die Kundenwebseiten nach Malware.
 
Danke für die zahlreichen Antworten!!

Sehe ich das richtig, dass wenn es sich um RFI handeln würde, der Inhalt des Platzierten DIVs (zb. der darin enthaltene Link) irgendwo als GET-Parameter in den access-Logs auftauchen müsste?
Diese Verfahren würde doch aber sicher die Modified-Zeitstempel der verändereten Dateien verändern, oder nicht?!
 
Vielleicht auch so?

Code: 
echo "<div style=\"overflow:auto; visibility:hidden; height: 3px; \"><ul> <a href=\"http://url.zu.einer.blogseite.mit.pornobildern/\">anstössiges wort</a> </ul></div>" >> /var/www/*/index.php
 
Hab da noch was gefunden, folgende Ausgabe von krhunter:

/usr/sbin/unhide [ Warning ]
/usr/sbin/unhide-linux26 [ Warning ]
/usr/local/bin/lwp-request [ Warning ]


Leider gibt rkhunter dazu keine weiteren Infos...ist da eventuell was faul?
Soll ich mit diesen Binarys irgendwas unternehmen? löschen? Neu installieren?
 
hagim said:
Diese Verfahren würde doch aber sicher die Modified-Zeitstempel der verändereten Dateien verändern, oder nicht?!
Click to expand...
Code: 
man touch

ProFTPd war aktuell, inklusive gefixtem mod_sftp? Exim als MTA? Jegliche WebApps aktuell? Alle Dienste sauber konfiguriert?

Hast Du mitlerweile alle Deine Kunden pflichtgemäss über den Sachverhalt aufgeklärt?

Nachtrag: Du wurdest definitiv gerooted...
 
Ja das System war aktuell (Nach aptitude).
Für ProFTP standen keine updates an...mod_sftp ist nicht aktiv.
Die CMS-Systeme sind alle auf dem nuesten Stand, jedoch hat es auch Kunden die direkten FTP-Zugang haben und somit sind die abgelegten Skripte nur schwer zu überwachen...
Kunden werden natürlich umghend informiert...

Gibt es noch andere Mittel um herauszufinden ob und wie der Server gerootet wurde ausser rkhunter/chkrootkit?
 
Er wurde definitiv kompromittiert. Um das warum herauszufinden: Logs durchsuchen. Rkhunter und Co. können dir nur Hinweise geben was nicht passt, aber nicht warum.

Also wie oben schon mal erwähnt: Lücke in den Logs suchen und anschließend sofortige Neuinstallation.... Bitte lass das Ding nicht länger als nötig so am Netz...
 
Okay, vielen Dank an alle für die schnelle Auskunft.
Ich werd mir jetzt mal die Nacht mit Logs durchsuchen um die Ohren schlagen.
Als erste Massnahme habe ich mal per monit eine Überwachung eingerichtet, die alle betroffenen Dateien per Checksum-Vergelich überwacht und ich lasse nur die allerwichtigsten Dienste und Websites laufen.

Morgen werde ich sofort ein neues System aufsetzen...da aber mein letztes Howto offenbar gewisse Schwächen/Lücken hatte...weiss einer eine gute Anleitung für einen Debian-Webserver bei der ich sicher gehen kann, sämtliche Sicherheitsmassnahmen zu beachten?
 
hagim said:
Ja das System war aktuell (Nach aptitude).
Für ProFTP standen keine updates an...mod_sftp ist nicht aktiv.
Click to expand...
Die aktuelle ProFTPd-Sicherheitslücke (in mod_sftp) ist bei Debian nicht gefixt, womit ProFTPd als Einfallstor in Frage kommt, zumal mehrere entsprechende Exploits kursieren.

Es kommt jedenfalls viel Arbeit auf Dich zu, viel Erfolg dabei.
 
Mod_php ist für ein System mit 200+ Webseiten auch das falsche Konzept. Kein Wunder, dass alle Seiten verändert worden sind. Ich tippe auch darauf, dass es einen Angriff via RFI gab, eine Shell nachgeladen wurde und dann kam es zu den Veränderungen, das ist ziemlich klassisch.

Du solltest die User voneinander separieren (suxec), wenn einer fällt, wird nicht unbedingt gleich die ganze Kiste mitgerissen (da die Userskripte nicht mehr als www-data wüten dürfen und die Rechtevergabe auf Dateiebene strikter erfolgen kann). Zusätzlich kann man per PHP noch "weich" chrooten (open_basedir). Ist zwar nur auf Anwendungsebene, aber besser als nichts.

Und proftpd: Ich weiss schon, warum diese Krücke bei mir isoliert in einem eigenen VE steckt...
 
Last edited by a moderator:
Danke für die Hinweise.
Wenn ich jetzt ein neues System konfiguriere, möchte ich natürlich alles optimal machen...hat jemand einen Tipp für eine gute Gesamtanleitung für einen Webserver wie ich ihn haben müsste...eventuell ein Buch oder ein komplettes Howto?
 
You must log in or register to reply here.
Back
Top