Menu

Sicher ? Sicherlich ! WordPress absichern.

Bei einem der Themes das ich nutzen mußte gab es Probleme zwischen zwei installierten Plugins. Eines der involvierten Plugins war ein sogenanntes Securetyplugin. Im Ergebnis war die Sicherheit im Eimer und ich stellte fest wie monströs dieses Sicherheitsplugin eigentlich war.
Ein Grund mich ein wenig auf Spurensuche zu begeben und zu Fuss das zu tun, was diese besonderen Sicherheits-Plugins sonst erledigen.
Sichere Passwörter nutzen, nicht benötigte Themes löschen, Tabellen-Präfix ändern, Authentication Unique Keys …, dies sind Dingelchens die bei einer routinierten Installation abzuspulen sind. Aber was gibt es noch ?

Ein Top-Act, der in Regel von sehr bequemen WP-NutzerInnen zusätzliche Mühen erfordert: Sichere das Verzeichnis /wp-admin bzw. die wp-login.php mit einer htaccess und htpasswd.
Beachte: Die login.php mit einer htaccess zu sichern erzwingt doppelte PW-Eingabe bei passwortgeschützten Beiträgen.

Ob des Sinns immer wieder diskussionswürdig ist der Einsatz von Plugins wie Login LockDown (nach 2 Jahren gab es mal wieder ein Update im September 2016) oder Limit Login Attempts. Diese Plugins sorgen dafür, daß nach mehreren falschen Login-Versuchen im WP-Backend die entsprechende IP gesperrt wird. Gegen wenig ambitionierte Hacker gut einzusetzen. Jedoch kaum wenn die Attacken im sekundentakt von hunderten verschiedener IPs kommen.
Login LockDown legt zwei Tabellen in der Datenbank an. Wenn du Zeit hast kannst du dir besonders nervige IP-Bereiche aus dem protokolliertem Pool holen (und bei Bedarf sperren). Und wenn du nachschaust wirst du feststellen, das eine der Tabellen mit der Zeit recht aufgeblasen wird: Leeren.

Falls es klar und übersichtlich ist welche NutzerInnen das WP-Backend nutzen: Der WP-Admin Zugang ließe sich via htaccess auf bestimmte IP-Adressen (IP-Ranges) beschränken.

Die XML-RPC-Schnittstelle ist ein Tool um mittels Desktop– bzw. Smartphone-Apps die Website / Artikel zu verwalten. Angeblich basieren viele Funktionen des Jetpack-Plugins auf dieser Schnittstelle. Wer zum Besipiel über ein externes Tool via XML-RPC-Schnittstelle zugreifen will, durchläuft eine zusätzliche Authentifizierung (RPC = Remote Procedure Call / entfernte Funktionsaufrufe, strukturiert mit xml). Deaktiviere mit folgendem Code in der function.php
/* Disable XMLRPC */
add_filter( 'xmlrpc_enabled', '__return_false' );

Der XMLRPC Tag erscheint jedoch weiterhin im HTML-Header. Soll er dort verschwinden ergänze in der function.php
/* Remove XMLRPC, WLW, Generator and ShortLink tags from header */
remove_action('wp_head', 'rsd_link');

Oder über die htaccess abschalten:
#XML-RPC Schnittstelle abschalten
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>

Das Directory Browsing ist bei den meisten Servern eh abgeschaltet, aber schau nach und verhindere es ggfs. In die htaccess kommen folgende zwei Zeilen:
# Prevent Directory Listings
Options -Indexes

Das wp-include Verzeichnis vor Zugriffen von aussen schützen.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^wp-admin/includes/ - [F,L] RewriteRule !^wp-includes/ - [S=3] RewriteRule ^wp-includes/[^/]+\.php$ - [F,L] RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L] RewriteRule ^wp-includes/theme-compat/ - [F,L] </IfModule>

Mit diesem Schnippsel gibts Probleme bei multi sites. Entferne:
RewriteRule ^wp-includes/[^/]+\.php$ – [F,L]

To ensure no .php files can be executed, create a .htaccess file in /wp-content/uploads containing following code (mittels Files oder FilesMatch):
<Files *.php>
deny from all
</Files>

Oder
<FilesMatch .php>
Order Deny,Allow
Deny from All
</Files>

Oder
# Ab Apache 2.4
# Disable direct access of any *.php files in /wp_content/uploads folder
<FilesMatch \.php$>
Require all denied
</FilesMatch>

Zugriffe über die htaccess regeln – einzeln oder im Pack:
<Files license.txt>
order allow,deny
deny from all
</Files>
# Protect wp-config.php and other files
<FilesMatch "(.htaccess|.htpasswd|wp-config.php|liesmich.html|readme.html)">
Order deny,allow
Deny from all
</FilesMatch>

Zur Erkennung des Benutzer-Accounts gebe in die Adresszeile des Browsers ein: meine-domain.com/?author=1. So kannst du 10 IDs durchprobieren und die dazugehörigen Nutzernamen herausfinden. Über folgenden Eintrag in die htaccess ließe sich das unterbinden:
RewriteCond %{REQUEST_URI} ^/$
RewriteCond %{QUERY_STRING} ^/?author=([0-9]*)
RewriteRule ^(.*)$ http://www.geh-weg.da/irgendwohin/? [L,R=301]

In einem laufenden Projekt eine Seite vorübergehend via htaccess schützen, suche: Verzeichnisschutz für Rewrite Pfade

Weitere Einstellungen in der .htaccess: perishablepress.com/6g/ (aka the 6G Blacklist)

WordPress empfiehlt: codex.wordpress.org/Hardening_WordPress

Beim schrauben an der htaccess kann die Apache-Version eine Rolle spielen. Syntaxbeispiele:
kuketz-blog.de/basisschutz-wordpress-absichern

CHMOD: Nicht nur der config.php reichen im Idealfall 0400-Rechte, also nur Leserechte und nur für den Besitzer (Nicht bei allen Anbietern möglich.). Auch die htaccess muß nur lesbar sein. Hast du die volle Kontrolle über das Projekt kannst du Template Dateien oder auch eigene Plugins auf nur lesbar setzen.
Die header.php, footer.php, index.php und functions.php sind mindestens dafür interessant.

Schraubst du in deinen php-files Dinge fehlerhaft zusammen erscheinen nicht nur einfache Fehlermeldungen, sondern es werden gleich die Pfade präsentiert. Teste verschiedene Möglichkeiten dies zu unterdrücken.
Via htaccess: php_flag display_errors off
Via config.php: define('WP_DEBUG', false);
Via config.php: define('WP_DEBUG_DISPLAY', false);
Via config.php: ini_set ('display_errors', 0);

Wenn verhindert werden soll, daß im WP-Backend Themes und Plugins geändert werden können, schreibe in die config.php:
define('DISALLOW_FILE_EDIT', true);

Ein kleines todo für die function.php um die Versionsnummern-Ausgabe zu entfernen / verschleiern:
remove_action('wp_head', 'wp_generator');
Wenn du das inkonsequent machst, kann jedoch z.B. in der readme.html selbiges von bösen Wichten ausgelesen werden kann. Schau mal hier: http://www.isitwp.com/

WP login errors in der function.php ändern:
add_filter('login_errors', create_function('$a', "return 'Oops! its wrong';"));

Begrenze die Anzahl der Nutzer die Zugriff auf das Backend haben. Es gibt viele Projekte bei denen sich im Laufe der Zeit überflüssige Nutzer*Innen ansammeln, entferne diese Karteileichen. Und versuche in Absprache mit dem Kunden die eingetragenen NutzerInnen mit Adminrechten zu reduzieren/begrenzen.

Um Seiten zu editieren sind keine Adminrechte notwendig. Lege dir ggfs. einen zusätzlichen Nutzer für solche Aufgaben an. Gerade wenn der Zugang unsicher erscheint (von unterwegs ?): benutze nicht den Adminzugang.

Falls es doch mal notwendig sein sollte ändere zwecks Verschleierung nachträglich den DB-Päfix, wenn er noch wp_ lautet. wpkrauts kommen zu dem Schluss: The database table prefix is not a security feature… It doesn’t matter what the prefix is … So why is the prefix a configuration option at all? It allows you to run more than one installation in the same database.
Benutze dafür ein Plugin oder tätige es per Hand: in der config.php den Präfix ändern, Tabellen umbenennen und vergesse nicht: Ein Update der Felder in den Tabellen „usermeta“ und „option“.

Und Mogli, vergiss nicht: Backups. Und das alte Backup nicht gleich überschreiben. Denn falls du es nicht mitbekommst legts du ein verseuches Backup an und spielst es wieder ein.
Ein automatisiertes Backup der Datenbank legst du zum Beispiel mit dem Plugin updraftplus auf dem Server an. Bedenke das du im Ernstfall immer ftp-Zugriff brauchst um an diese Datenbank-Backups ranzukommen. Gespeichert werden die standardmäßig in: wp-content/updraft.

Halte die Datenbank sauber: Optimierung und Bereinigung der WordPress Datenbank. Suche ein Plugin wie WP-Optimize oder WP Clean UP.
Wenn der Kunde erste Übungen mit seinem 59-USD-Theme anstellt und du die ersten Datenbankbackups anlegst und du dich über 9MB große Datenbanken wunderst, dann prüfe in der config.php ob die Anzahl der zu speichernden Versionen wirklich so hoch sein muß: define( 'WP_POST_REVISIONS', 15 );
Ganz abschalten: define('WP_POST_REVISIONS', FALSE);
Zur Funktion Autosave: Diese Funktion speichert immer nur eine Kopie deines Artikels. Das Zeitintervall zu erhöhen reuziert zwar Datenbankzugriffe wenn du arbeitest, aber die Datenbankgröße wird dadurch nicht nachhaltig beeinflußt.

Aufreger Emoji, Smilie ähnliche Grafiken/Icons. Diese Funktionalität ist in WordPress (fest) integriert und die scripte werden immer geladen. Unnötigerweise wenn sie nicht gebraucht werden. Neben der Performance-Kritik gibt es Tracking-Kritik, da die Icons von einem externen Server geladen werden.
Um Emoji abzuschalten schreibe in die functions.php
//* Disable the emoji's */
function disable_emojis() {
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'admin_print_scripts', 'print_emoji_detection_script' );
remove_action( 'wp_print_styles', 'print_emoji_styles' );
remove_action( 'admin_print_styles', 'print_emoji_styles' );
remove_filter( 'the_content_feed', 'wp_staticize_emoji' );
remove_filter( 'comment_text_rss', 'wp_staticize_emoji' );
remove_filter( 'wp_mail', 'wp_staticize_emoji_for_email' );
add_filter( 'tiny_mce_plugins', 'disable_emojis_tinymce' );
}
add_action( 'init', 'disable_emojis' );

/* Remove the TinyMCE emoji plugin */
function disable_emojis_tinymce( $plugins ) {
if ( is_array( $plugins ) ) {
return array_diff( $plugins, array( ‚wpemoji‘ ) );
} else {
return array();
}
}

Ein wenig zum Thema Datenschutz, google-fonts und gravatare im WP-Backend:
journalismus-plus.de/generieren/spionageprogramme-in-wordpress-deaktivieren

robots.txt und Bots … nett zu lesen:
perishablepress.com/wordpress-robots-rules/
perishablepress.com/blackhole-bad-bots/

last modified:04.08.2017
it is in:   Allgemein   Wordpress