Brutforce Angriff auf Admin Login - diesmal mit korrekten Usernnamen

Hänge einfach an Deine URL /?author=1 oder /?author=2 oder /?author=3 usw. an. Also http://deinedomain.de/?author=1

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.

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

Zitat

/?author=1

Na danke. (auch wenn ich die 2 bin :twisted:)
http://forum.wpde.org/allgemeines/136445-sicherheit.html
Warum steht in dieser URL denn nicht mein öffentlicher Name?

deineseite.de?author=1
deineseite.de/?irgendwas&author=1

Hmmmm, entweder ich geb mir eine schön hohe ID, oder ich werde wohl eher gleich die kompletten Authorseiten sperren.

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?

Zitat von himitsu

Hmmmm, entweder ich geb mir eine schön hohe ID, oder ich werde wohl eher gleich die kompletten Authorseiten sperren.

Einfach den Author Slug ändern. Benutzer, öffentlichen Namen und Slug unterschiedlich gestallten. Und natürlich den Benutzernamen niemals als öffentlichen Namen verwenden. Auf diese Weise können Benutzernamen nicht mehr "ausgelesen" werden.

Das klingt auch gut.

War grade mal in den Logs.
Die letzten 1-2 Wochen hatte zumindestens keiner diesen Author-Link-Trick benutzt.
Die wenigen Loginversuche der letzten 5 Wochen gingen einmal gegen "admin", den es nicht gibt, und ansonsten ging es ausschließlich gegen meinen öffentlichen Namen.
Aktuell versucht einer es gegen Passwort "öffentlicher Name"+"angebliches Geburstjahr" (1986, 1987, 1989, ...) und so jung bin ich nu och nimmer.
Aber im Login sind Angriffe aktuell stark gesunken (man konzentriert sich seit Dezember dafür vermehrt wieder darauf in den Kommentaren erfolglos rumzuspammen.

Bei mir läuft fail2ban. Ich habe rund 200 Loginversuche pro Tag und etwa 1000 Hex-Hacks (Proxy Scans, URL Exploits, usw.). In etwa 95% davon kommen aus Asien (China, Taiwan).

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.

Zitat von b3317133

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.

Oder über eine Funktion abfangen.

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.

Ich denke da eher an eine Funktion, die die Fehlversuche aufzeichnet und die IP sperrt, nach dem Model

function mensmaximus_log_xmlrpc($arg) {
	/* 
		REMOTE_ADDR holen und in Transient speichern
		Parameter für max. Fehlversuche aus DB lesen
		Abgleich über Transients durchführen
		Bei positivem match IP sperren
	*/
	return $arg;
}


add_filter('xmlrpc_login_error', 'mensmaximus_log_xmlrpc');
add_filter('wp_login_failed', 'mensmaximus_log_xmlrpc');

Wie gesagt ist eine Idee.

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.

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.

Zitat von b3317133

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.

muplugins_loaded kommt bestimmt davor ;-) Das ist aber auch gar nicht weiter nötig. Mit wp_authenticate steht einem der notwendige Hook zur Verfügung, da er vor der eigentlichen Authentifizierung stattfindet.

Grundsätzlich sind wir uns aber wahrscheinlich alle einige, dass Abwehrmaßnahmen dieser sowieso außerhalb von WordPress stattfinden sollten (IP-Tables, Fail2Ban oder mit vorgeschalteten Proxy-, Firewall- oder IPS-Systemen).