Beiträge von b3317133

Alte Versionen von FileZilla Client.

[FONT=courier new]locals.php[/FONT] ist keine standard WordPress Datei. Sie muss also vom Theme selbst geladen werden. Würde in allen Dateien des Parent Theme nach dem Text [FONT=courier new]locals.php[/FONT] suchen, das sollte dann zeigen, wie/wo man sie entspr. im Child Theme einbinden muss.

Jetzt ist der Eintrag da, aber es fehlt die [FONT=courier new]}[/FONT] beim vorherigen Eintrag [FONT=courier new]#searchform input[type="text"]

[FONT=lucida sans unicode]Ergänzung: Und jetzt ist die [FONT=courier new]} [/FONT]da und es klappt alles.[/FONT]
[/FONT]

Zitat von filmfreaks

hat leider nicht geholfen ):

Der Eintrag hilft sicher. Aber er befindet sich weder im [FONT=courier new]style.css[/FONT] des Themes noch des Child-Themes.

Ergänze z.B. diesen Eintrag in [FONT=courier new]simplemag/style.css[/FONT]

.wpcf7-form-control-wrap.acceptance-65 {
    display: inline-block;
}

Derzeit ist meines Erachtens die einzige Lösung mit WordPress-Bordmitteln das Abschalten der XML-RPC Schnittstelle in [FONT=courier new]functions.php[/FONT] via

add_filter( 'xmlrpc_enabled', '__return_false' );

und das Entfernen der damit nutzlosen [FONT=courier new]<link rel="pingback" href="<?php bloginfo( 'pingback_url' ); ?>" />[/FONT] o.ä. in [FONT=courier new]header.php[/FONT] oder sonstwo im Theme. Bitte gern andere Vorschläge zu XML-RPC posten.

Für Bruteforce bei normalen Logins mit den üblichen Account-Namen bevor überhaupt Plugins o.ä. geladen bzw. die Datenbank connected wird, nutze ich einen Code-Block wie z.B. diesen in der [FONT=courier new]wp-config.php[/FONT]

/* stop brute force account hacking */
if ( isset( $_POST ) && isset( $_POST['log'] ) && (
        strpos( $_POST['log'], '}' ) !== false // z.B. '{domain}' '{domen}'
        || strpos( $_POST['log'], ' ' ) !== false // names with space chars
        || ( in_array(
                strtolower( trim( $_POST['log'] ) ),
                array( 'admin', 'administrator', 'root', 'test', 'manager', 'server', 'support'
                    , 'superadmin', 'admin1', 'developer', 'webmaster'
                    , 'editor', 'wp_admin', 'wpadmin'
                )
            )
        )
    ) ) {
    // redirect to protected folder with "Deny from all", causes 403 error & entry in apache error-log
    header( 'Location: http://' . $_SERVER['SERVER_NAME'] . '/forbidden/' );
    exit;
}

Das reduziert die Serverlast erheblich...

Ergänzung: Oft wird als Login auch der Domainname ohne www. und .de/.com versucht, oder E-Mail Adressen die auf dem Website vorkommen. Die trage ich dann noch in das o.g. Array ein.

Wie verhindert man dann den nächsten Loginversuch der aufgezeichneten IP?

WordPress XML-RPC stellt meines Wissens keine Filter/Actions vor dem XML-RPC Loginversuch zur Verfügung.

Zitat von mensmaximus

Oder über eine Funktion abfangen.

Über welche genau?

Zitat von Alfahoster

add_filter( 'xmlrpc_enabled', '__return_false' );

Das schaltet die Schnittstelle ab.

Es gibt auch viele Loginversuche via XML-RPC, die werden oft vergessen bei der "Verteidigung". Die einzige echte Lösung hier ist das Abschalten der Schnittstelle.

robce meint wohl eher
http://codex.wordpress.org/Using_Password_Protection

Stimmt, "irgendwas&" ist durchgerutscht, hier eine angepasste Version:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_URI} ^/$
RewriteCond %{QUERY_STRING} (^/?|&)author=([0-9]*)
RewriteRule ^(.*)$ $1?author=999999 [L]
</IfModule>

Noch weitere Lücken?

Die Zeile [FONT=courier new]Options +FollowSymlinks[/FONT] ist nicht erforderlich, war ein copy&paste Fehler... :oops:

Diese Art des Angriffs kann man z.B. so verhindern, vor dem WordPress-Block in [FONT=courier new].htaccess[/FONT] setzen, die [FONT=courier new]RewriteBase[/FONT] ggf. anpassen.

<IfModule mod_rewrite.c>
Options +FollowSymlinks
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_URI} ^/$
RewriteCond %{QUERY_STRING} ^/?author=([0-9]*)
RewriteRule ^(.*)$ $1?author=999999 [L]
</IfModule>

Das leitet alle o.g. URLs intern zu einem User mit ID 999999 weiter, den es aber (höchstwahrscheinlich) nicht gibt und daher eine 404-Seite anstelle der Autor-Seite geliefert wird.

WordPress 3.8 ist über ein Jahr alt...

Dann kann es eigentlich nur noch an einem Add-On von Firefox liegen. Mal testweise alle Add-Ons deaktivieren.

Beim Beitrag "Wer sind wir und was machen wir hier?" auf der Startseite wird das Bild in Originalgrösse 4592*3056 Pixel eingebunden und verursacht dadurch eine hohe Ladezeit. Das sollte man mal überprüfen. Beim Beitrag "Oskar & Balu" wird das Bild dagegen richtig eingebunden.

Klappt es mit der Authentifizierung, wenn Du in den Webmaster Tools die Methode "HTML-Datei hochladen" verwendest?

https://support.google.com/webmasters/answer/35658?hl=de

Würde im FireFox mal testweise die Cookies löschen. Hilft das?

Der Menu-Button ist durch das negative [FONT=courier new]top: -56px[/FONT] bei [FONT=courier new].dl-menuwrapper button[/FONT] in [FONT=courier new]style.css[/FONT] oben ausserhalb, evtl. ist [FONT=courier new].dl-menu[/FONT] auch zu weit oben o.ä., habe ich nicht weiter verfolgt.