6
Php-Scripte auf Schadcode prüfen
Hallo! Ich habe für einen Kunden u.a. ein CMS installiert, das auf php basiert, bei einem Billig-Provider installiert. Nun muss ich die Dateien auf Schadcode Scannen.
Ich habe für einen Kunden u.a. ein CMS, das auf php basiert, bei einem Billig-Provider installiert. Nun möchte ich die Dateien auf Schadcode scannen. Es gab vor einigne Tagen tatsächlich einen erfolgreichen Angriff auf den Server. Zwei zusätzliche Verzeichnisse wurden wurden im htdocs meines Kunden installiert, von denen aus Spam-Mails verschickt wurden. Diese Verzeichnisse wurden zwar gelöscht, aber der Kunde möchte trotzdem, daß ich alle Dateien auf dem Server auf weiteren Schadcode scanne. Wie gehe ich da vor? Welche Software verwende ich da. Ich habe nur FTP bzw. SSH-Zugriff...
Vielen Dank für Eure Hilfe!
Ich habe für einen Kunden u.a. ein CMS, das auf php basiert, bei einem Billig-Provider installiert. Nun möchte ich die Dateien auf Schadcode scannen. Es gab vor einigne Tagen tatsächlich einen erfolgreichen Angriff auf den Server. Zwei zusätzliche Verzeichnisse wurden wurden im htdocs meines Kunden installiert, von denen aus Spam-Mails verschickt wurden. Diese Verzeichnisse wurden zwar gelöscht, aber der Kunde möchte trotzdem, daß ich alle Dateien auf dem Server auf weiteren Schadcode scanne. Wie gehe ich da vor? Welche Software verwende ich da. Ich habe nur FTP bzw. SSH-Zugriff...
Vielen Dank für Eure Hilfe!
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 135951
Url: https://administrator.de/forum/php-scripte-auf-schadcode-pruefen-135951.html
Ausgedruckt am: 13.03.2025 um 17:03 Uhr
6 Kommentare
Neuester Kommentar
Hi !
Das CMS samt Datenbank runterhauen und ein (hoffentlich vorhandenes) Backup einspielen und danach das CMS auf die aktuelle Version updaten. Das Wissen über einen Check, ob es sich um die originalen CMS-Files handelt, setze ich jetzt einfach mal voraus. Wenn man keine Root-Rechte auf dem Server hat, dann unbedingt auch den Provider mit ins Boot holen.
Wir haben z.B. zu unserer Absicherung für jeden Kunden die komplette Grundinstallation (natürlich ohne die nachträglichen Änderungen des Kunden) noch einmal auf unseren lokalen Servern, falls das Produktivsystem einmal komplett Tot ist und beim Kunden kein Backup vorhanden sein sollte, was es ja schon mal hätte gegeben haben können. :-P
mrtux
Das CMS samt Datenbank runterhauen und ein (hoffentlich vorhandenes) Backup einspielen und danach das CMS auf die aktuelle Version updaten. Das Wissen über einen Check, ob es sich um die originalen CMS-Files handelt, setze ich jetzt einfach mal voraus. Wenn man keine Root-Rechte auf dem Server hat, dann unbedingt auch den Provider mit ins Boot holen.
Wir haben z.B. zu unserer Absicherung für jeden Kunden die komplette Grundinstallation (natürlich ohne die nachträglichen Änderungen des Kunden) noch einmal auf unseren lokalen Servern, falls das Produktivsystem einmal komplett Tot ist und beim Kunden kein Backup vorhanden sein sollte, was es ja schon mal hätte gegeben haben können. :-P
mrtux
Moin,
ein, zugegeben etwas aufwändiger, Weg wäre der folgende:
Original des CMS Systems besorgen, Produktionssystem per FTP abziehen und dann die MD5 Checksumme der jeweiligen Files vergleichen.
Aber was viel wichtiger ist: Quelle des Einbruchs lokalisieren und eliminieren. Notfalls Provider wechseln.
lg,
Slainte
ein, zugegeben etwas aufwändiger, Weg wäre der folgende:
Original des CMS Systems besorgen, Produktionssystem per FTP abziehen und dann die MD5 Checksumme der jeweiligen Files vergleichen.
Aber was viel wichtiger ist: Quelle des Einbruchs lokalisieren und eliminieren. Notfalls Provider wechseln.
lg,
Slainte
Mit einem SVN wäre das wohl kein Problem, macht auch die Entwicklungsarbeit viel leichter. Probleme macht es nur, wenn ein CMS den Code in der Datenbank ablegt, dann muss das natürlich auch regelm. gespeichert werden.
Ggf. einfach mal nach allen Dateien suchen die den entsprechenden Änderung Zeitstempel haben. Aber kann mit nicht vorstellen das etwas geändert wurde, so etwas dauert einfach zu lange. Die werden nur schnell ihre die Dateien hochgeladen haben.
Ggf. einfach mal nach allen Dateien suchen die den entsprechenden Änderung Zeitstempel haben. Aber kann mit nicht vorstellen das etwas geändert wurde, so etwas dauert einfach zu lange. Die werden nur schnell ihre die Dateien hochgeladen haben.
Moin,
Nach einem Einbruch ist der komplette Server als nicht mehr vertrauenswürdeig inzustufen und gehört daher eingentlich platt gemacht und neu installiert - von sauberen Quellen versteht sich.
lg,
Slainte
so etwas dauert einfach zu lange
Ein IFRAME mit einem Link zu einer Drive-by-download ist schnell wo 'reinkopiert... zombies installieren bringt Geld, und das macht erfinderisch, glaub mir Nach einem Einbruch ist der komplette Server als nicht mehr vertrauenswürdeig inzustufen und gehört daher eingentlich platt gemacht und neu installiert - von sauberen Quellen versteht sich.
lg,
Slainte
Meistens ist die größte Sicherheitslücke aber auch der Kunde selbst.
Wenn der FTP-Account geknackt wurde, nützt das sicherste CMS nichts - und wenn unsichere Kennwörter für den Backend-Login verwendet wurden, auch nicht.
Wenn der FTP-Account geknackt wurde, nützt das sicherste CMS nichts - und wenn unsichere Kennwörter für den Backend-Login verwendet wurden, auch nicht.
was mir da so sponan einfiele wäre:
die sourcen von der website ziehen, original cms lziehen beides ablegen in getrennten ordner
und mit ein wenig shellscripting und diff das ganze durchlaufen lassen und eine "vergleichsliste"
erstellen.
soweit iich weis würd da sogar diff alleine reichen mal schaun ob ich das script noch irgendwo finde..
grüße
die sourcen von der website ziehen, original cms lziehen beides ablegen in getrennten ordner
und mit ein wenig shellscripting und diff das ganze durchlaufen lassen und eine "vergleichsliste"
erstellen.
soweit iich weis würd da sogar diff alleine reichen mal schaun ob ich das script noch irgendwo finde..
grüße
