• Hallo liebe Userinnen und User,

    nach bereits längeren Planungen und Vorbereitungen sind wir nun von vBulletin auf Xenforo umgestiegen. Die Umstellung musste leider aufgrund der Serverprobleme der letzten Tage notgedrungen vorverlegt werden. Das neue Forum ist soweit voll funktionsfähig, allerdings sind noch nicht alle der gewohnten Funktionen vorhanden. Nach Möglichkeit werden wir sie in den nächsten Wochen nachrüsten. Dafür sollte es nun einige der Probleme lösen, die wir in den letzten Tagen, Wochen und Monaten hatten. Auch der Server ist nun potenter als bei unserem alten Hoster, wodurch wir nun langfristig den Tank mit Bytes vollgetankt haben.

    Anfangs mag die neue Boardsoftware etwas ungewohnt sein, aber man findet sich recht schnell ein. Wir wissen, dass ihr alle Gewohnheitstiere seid, aber gebt dem neuen Board eine Chance.
    Sollte etwas der neuen oder auch gewohnten Funktionen unklar sein, könnt ihr den "Wo issn da der Button zu"-Thread im Feedback nutzen. Bugs meldet ihr bitte im Bugtracker, es wird sicher welche geben die uns noch nicht aufgefallen sind. Ich werde das dann versuchen, halbwegs im Startbeitrag übersichtlich zu halten, was an Arbeit noch aussteht.

    Neu ist, dass die Boardsoftware deutlich besser für Mobiltelefone und diverse Endgeräte geeignet ist und nun auch im mobilen Style alle Funktionen verfügbar sind. Am Desktop findet ihr oben rechts sowohl den Umschalter zwischen hellem und dunklem Style. Am Handy ist der Hell-/Dunkelschalter am Ende der Seite. Damit sollte zukünftig jeder sein Board so konfigurieren können, wie es ihm am liebsten ist.


    Die restlichen Funktionen sollten eigentlich soweit wie gewohnt funktionieren. Einfach mal ein wenig damit spielen oder bei Unklarheiten im Thread nachfragen. Viel Spaß im ngb 2.0.

[Wordpress] Schneller und sicherer

LadyRavenous

in Schwarz
Teammitglied

Registriert
26 Dez. 2016
Beiträge
16.080
Ort
hello world
Auch wenn ich keinen Traffic benötige, gefällt mir der Aufruf bei Traffic-Gefahr (mit der Hoffnung, dass einige How-Tos ins Board wandern) und wenn man sich privat mal wieder mit Wordpress beschäftigt...

In dieser Übersicht möchte ich nicht beschreiben, wie man Seiten oder Beiträge erstellt, sondern welche Online-Tests sinnvoll sind, was man bzgl. Sicherheit aufpassen sollte usw. Der Plan ist, dass noch mehr Beiträge von mir kommen und ich würde mich freuen, wenn sich auch noch andere beteiligen.
Als Einstieg eignet sich übrigens der Hardening WordPress Guide von Wordpress.

Eigener Rechner

Natürlich muss dein Rechner, mit dem du auf das Backend zugreifen willst, möglichst sicher sein. Bei öffentlichen Wlans lieber VPN benutzen.

Aktuell bleiben

Newsletter von WPScan Vulnerability Database oder das Security Archiv von Wordpress regelmäßig lesen.

Zusätzlich sollte man sich auf die Developer Mailinglisten setzen, um mitzubekommen, ob Plugins und Themes gewartet werden. Externe Teile der Wordpress Installation sind Angriffsvektor Nr 1!

Aktualisieren

Allgemein sollten Wordpress und Plugins immer aktuell sein. Sind Plugins veraltet, sollten diese ersetzt werden. Unnötige Plugins gehören entfernt, um die Angriffsfläche zu verringern. Deaktivieren reicht übrigens nicht!
Themes sollten ebenfalls immer aktuell sein - außer man verändert sie.

Themes

Bei der Auswahl des Themes kann man schon darauf achten, dass es aktuell ist, responsive Design verwendet und dass es möglichst sicher ist. Letzteres ist schwieriger zu testen, außer man ist selbst gut im Code Review.
Habt ihr ein Theme ausgewählt, könnt ihr es anpassen. Deinstalliert möglichst alle anderen installierten Themes, um ebenfalls die Angriffsfläche zu verringern. Bei manchen lustigen Wordpressfehlern hilft es auf ein anderes Theme zu wechseln, wodurch ich immer noch ein weiteres installiert habe. Wer wenig bastelt, benötigt es nicht.

Themes anpassen: mit zusätzlichem CSS kann man das Design (Farbe, Schriftart und ähnliches) in den Themes anpassen. Sind größere Anpassungen nötig, damit ihr zufrieden seid, könnt ihr entweder im Theme selbst schreiben (und dann nicht mehr updaten, da sonst die Änderungen alle weg sind) oder ein Child-Theme anlegen. Letzteres hat bei mir nie so wirklich geklappt.

Wer es wie ich nicht geschafft hat, ein Childtheme zu erstellen und nicht in Versuchung geraten will, das Theme zu aktualisieren, kann mit diesem Snippet innerhalb von functions.php es schaffen, dass Theme-Updates gar nicht mehr angezeigt werden. Aber Achtung, Updates bzgl. Sicherheit solltet ihr trotzdem irgendwie nachziehen können! Ein nettes Tutorial, was ich leider erst jetzt kennen gelernt habe, ist Andreas Hecht Use Child Theme.

[src=php]remove_action( 'load-update-core.php', 'wp_update_themes' );
add_filter( 'pre_site_transient_update_themes', create_function( '$a', "return null;" ) );
wp_clear_scheduled_hook( 'mng_17_update_themes' );[/src]

Plugins

Überlegt euch gut, welche Plugins ihr installiert, da auch Malware oder einfach fehlerreicher Code dabei sein kann. Je mehr Plugins, desto mehr Bugs können auch dabei sein.

Es gibt ziemlich viele Security Plugins, die verschiedene Probleme lösen sollen: Prävention, Detektion, Auditing und Zusatzfunktionalitäten.
Website Firewalls, Online Scanner, Application Scanner und File Integrity Monitoring sind wohl die üblichsten Plugin-Typen.
Persönliche Erfahrung: Firewall ist nett, aber kann die Site auch ziemlich verlangsamen. File Integrity Monitoring kann man sich selbst basteln und es gibt auch viel Schrott.

Security Plugins haben, wie alle Plugins, genauso viele Berechtigungen wie Wordpress Core (Designfehler meiner Meinung nach). Also Dokumentation und Bewertungen lesen und wenns geht evtl. auch den Code anschauen.

Benutzer

Verwende möglichst nicht den Benutzernamen admin und wähle starke Passwörter. Auch kann man den Benutzern unterschiedliche Berechtigungen zuweisen, also einen Admin-Account und einen Redaktionsaccount z.B.

Wer mehrere Wordpress-Installationen betreibt, sollte die Datenbanken voneinander trennen und unterschiedliche Identitäten die Datenbank verwalten lassen, damit bei einem Angriff nur eine Wordpress-Installation betroffen ist und nicht gleich mehrere.

Backups

Zieht regelmäßig (täglich) ein Backup der Datenbank und von Wordpress. Entweder könnt ihr das bei eurem Hoster einstellen (wenn ihr im vertraut), installiert ein Plugin oder habt ein passendes Script.
Ach ja, Backups testen soll nicht schaden, nicht dass man erst dann merkt, dass das Backup nicht funkioniert, wenn man es dringend braucht.
MW, könntest du vielleicht deines herzeigen? Soweit ich das sehe ist es besser als meine Lösung.

Logging

Logs können ebenfalls praktisch sein, um nicht autorisierte Änderungen an Dateien zu merken.

SSL

Der Sprung von HTTP auf HTTPS ist einfach im den allgemeinen Einstellungen möglich, viele Hoster bieten günstige oder kostenlose SSL-Zertifikate an. Einzig nervige ist, dass alle Bilder, die schon auf Wordpress hochgeladen und eingebunden sind, auf https umgestellt werden müssen. Auch können in Themes externe Quellen eingebunden sein, die HTTPS brechen.

Ein praktischer Scanner um zu sehen, auf welchen Seiten noch mixed content steht, ist der SSL-Scanner von Jitbit.
Falls ihr bei der Fehlerbehebung mit der Datenbank arbeiten wollt: in wp_posts sollten Links und Bilder eurer Site von http auf https geändert werden.
Falls ihr mehrere Quellen verlinkt, kann euch das Plugin Link Checker auch helfen von HTTP auf HTTPS umzustellen, da es Weiterleitungen erkennt (bei Links).
Andere Plugins sollen ebenfalls beim Umstieg helfen, aber davon habe ich keine ausprobiert.

Anschließend solltet ihr noch https erzwingen. Das habe ich in der .htaccess gemacht:

[src=apache]RewriteEngine On
RewriteCond %{HTTP_HOST} ^example\.com [NC]
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://example.com/$1 [R,L][/src]

FTP oder besser SFTP

Über SSH und FTP/SFTP könnt ihr auf das Backend zugreifen. Macht euch mit den Möglichkeiten, die euer Hoster euch bereitstellt, bekannt. SFTP und SSH sind dabei sicherer als FTP.

.htaccess

.htaccess ist eine Konfigurationsdatei vom Apache Webserver, die man dazu verwenden kann Cachezeiten, Komprimierungen und Zugriffe zu steuern.

[src=apache]# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_HOST} ^example\.com [NC]
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://example.com/$1 [R,L]
</IfModule>

<ifModule mod_gzip.c>
mod_gzip_on Yes
mod_gzip_dechunk Yes
mod_gzip_item_include file .(html?|txt|css|js|php|pl|jpeg|jpg)$
mod_gzip_item_include handler ^cgi-script$
mod_gzip_item_include mime ^text/.*
mod_gzip_item_include mime ^application/x-javascript.*
mod_gzip_item_exclude mime ^image/.*
mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
</ifModule>

<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
</IfModule>

## EXPIRES CACHING ##
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType text/css "access 1 month"
ExpiresByType application/pdf "access 1 month"
ExpiresByType text/x-javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
ExpiresByType image/x-icon "access 1 year"
ExpiresByType text/html "access plus 1 days
ExpiresByType text/javascript "access plus 1 month"
ExpiresByType text/xml "access plus 1 seconds"
ExpiresByType application/javascript "access plus 7 days"
ExpiresDefault "access 2 days"
</IfModule>

<filesMatch "\\.(css|jpg|jpeg|png|gif|js|ico|js.gz)$">
Header set Cache-Control "max-age=604800, private"
</filesMatch>

## EXPIRES CACHING ##

<IfModule pagespeed_module>
ModPagespeed on
# using commands,filters etc
</IfModule>

# Protect readme.html File
<Files readme.html>
order allow,deny
deny from all
</Files>

# Protect license.txt file
<Files license.txt>
order allow,deny
deny from all
</Files>[/src]

Diese .htaccess habe ich im Hauptverzeichnis.

  • mod_gzip und mod_deflate komprimieren bestimmte Dateien und machen eure Site dadurch schneller
  • mod_expires beschreibt, wie lange was gecacht werden soll
  • pagespeed_module: Beschleunigung der Site
  • Protect: dadurch können Zugriffe eingeschränkt werden.

Weitere Dateien, die möglichst nicht von außen lesbar sein sollten, sind readme.html, liesmich.html, licence.md, readme.txt, readme.md, wp-config.php.
Mit [src=apache]php_flag display_errors off[/src] kann man zudem Fehlermeldungen unterdrücken, damit ein potentieller Angreifer den Serverpfad nicht in Erfahrungen bringen kann. Unnötige Dateien, wie readme, kann man übrigens auch gleich löschen.

[src=apache]<Files *.php>
deny from all
</Files>[/src]

Diese in /wp-content/uploads/ schränkt das Hochladen von php-Dateien ein, damit niemand ausführenden php-Code hochladen kann. Include-Files sollen ebenfalls geblockt werden laut Wordpress Security.

[src=apache]# Block the include-only files.
<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>[/src]

Im Endeffekt:

  • Unnötige Dateien löschen oder Zugriff verhindern
  • Lizence, readme und liesmich zumindest den Zugriff sperren
  • WP-Admin: am besten Server-Seitig Passwort setzen, wodurch normale Nutzer nicht auf /wp_admin/admin-ajax.php zugreifen können.
  • WP-Includes: Skripte verbieten über obriges Skript
  • WP-Uploads: Skripte verbieten über eine .htaccess im entsprechenden Verzeichnis
  • WP-Config: im Root Verzeichnis


Wer noch mehr einstellen will, findet eine etwas längliche .htaccess von Hecht Media auf Github. Längere .htaccess kann wiederum die Geschwindigkeit verlangsamen, allerdings können viele Punkte auch die Sicherheit erhöhen.

Berechtigungen

Laut dem Guide von WordPress.org sollen Ordner die Berechtigung 755 oder 750 erhalten und nicht 777. Dateien haben am besten die Berechtigungen 640 oder 644, wp-config.php 600.

Erste Zahl: Was der Owner des Files machen kann
Zweite Zahl: Was andere Nutzer in der Gruppe des Owners machen können
Dritte Zahl: Was alle anderen Nutzer (inklusive Besucher) machen können

4: Lesen
2: Schreiben
1: Ausführen

6: Lesen und Schreiben (4+2)
7: Lesen, Schreiben und Ausführen (4+2+1)

Caching und Geschwindigkeit optimieren

Oben habe ich bereits von Cache-Control in .htaccess geschrieben. Zusätzlich gibt es Caching-Plugins, wie W3 Total Cache und WP Super Cache. Beides sind die am häufigsten verwendeten Plugins, zusätzlich gibt es noch andere die Multisites unterstützen (WP Fastest Cache), schlanke wie Cachify oder Comet Cache sowie WP Rocket, was auch Lazy Loading unterstützt.
Hier kann ich ausprobieren empfehlen. In meinem Fall brachte WP Super Cache das beste Ergebnis.

Ferner gibt es Plugins, die die Seiten verkleinern, wie JCH Optimize. Manches bringt was, manches verschlechtert die Ladezeit. Einfach ausprobieren.

CDN: solange man nicht Kunden auf verschiedenen Kontinenten oder größeren Regionen hat: bringt wenig, generiert vor allem Aufwand.

Allgemein hilft es DNS Lookups, Skripte und CSS zu reduzieren sowie Bilder zu optimieren.

Obscurity bzw. aktuell weniger relevante Methoden

Diese Methoden werden mehrmals genannt, haben aber auch Nachteile oder Risiken.

  • Login-Versuche beschränken: hilft nur bei einem einzelnen Angreifer, nicht bei Botnetzen.
  • File-Editieren über Browser verbieten, sondern nur über (S)FTP erlauben: define('DISALLOW_FILE_EDIT', true) in wp-config.php. Angriffsvektor einschränken, schmälert aber die Bequemlichkeit.
  • Versionsnummer, Login-Seite verstecken, User Enumeration entfernen
  • XML-RPC deaktivieren, vorausgesetzt kein Plugin benötigt es
  • Display-Namen in etwas anderes als die Login-Namen ändern.
  • Archive deaktivieren, wie bei wp-mix beschrieben.

Versionsnummer

Das Verschleiern der Version erschwert einen Angriff nur, wenn er gezielt ist. Ein breiter Angriff achtet häufig nicht auf die Versionsnummern, sondern wird einfach ausprobiert.
Die Version wird im wp_head durch wp_generator generiert und kann in functions.php im Theme abgestellt werden. Überlegt euch aber, was für euch sinnvoll ist und was nicht. Das ist meine Version:

[src=apache]remove_action('wp_head', 'wp_generator');[/src]

Zusätzlich kann man verwenden:

[src=apache]remove_action('wp_head', 'feed_links_extra'); //category feeds
remove_action('wp_head', 'feed_links', 2); //post and comment feeds
remove_action('wp_head', 'rsd_link'); //edituri link
remove_action('wp_head', 'wlwmanifest_link'); //windows live writer
remove_action('wp_head', 'links_rel_link'); //index link
remove_action('wp_head', 'parent_post_rel_link', 10, 0); // previous link
remove_action('wp_head', 'start_post_rel_link', 10, 0); //start link
remove_action('wp_head', 'adjacent_posts_rel_link_wp_head', 10, 0); //links for adjacent posts[/src]

User Enumeration

User Enumeration ist vor allem dann wichtig, wenn mehrere Nutzer an der Seite arbeiten und die Passwörter ggf. nicht stark genug sind.

User enumeration in functions.php unterbinden:
[src=php]// block WP enum scans
if (!is_admin()) {
// default URL format
if (preg_match('/author=([0-9]*)/i', $_SERVER['QUERY_STRING'])) die();
add_filter('redirect_canonical', 'shapeSpace_check_enum', 10, 2);
}
function shapeSpace_check_enum($redirect, $request) {
// permalink URL format
if (preg_match('/\?author=([0-9]*)(\/*)/i', $request)) die();
else return $redirect;
}[/src]

Alternativ User Enumeration in .htaccess blockieren

[src=apache]# Block User ID Phishing Requests
<IfModule mod_rewrite.c>
RewriteCond %{QUERY_STRING} ^author=([0-9]*)
RewriteRule .* http://example.com/? [L,R=302]
</IfModule>[/src]

XML-RPC

Die XML-RPC-Schnittstelle ist seit Version 3.5 standardmäßig aktiviert und kann für Brute-Force-Angriffe missbraucht werden. Manche Plugins benötigen sie, daher etwas mit Vorsicht genießen, wenn man sie deaktiviert. Die Schnittstelle dient zum Verwalten von Inhalten, wie auch für Pingbacks.

[src=php]/* Disable XMLRPC */
add_filter( 'xmlrpc_enabled', '__return_false' );[/src]

Die Schnittstelle ist deaktiviert, kann aber trotzdem angefragt werden. Esoterisch kann man jetzt die Schnittstelle im Header entfernen (was man nicht sieht, greift man nicht an *hust), indem man folgendes Snippet in der functions.php einfügt:

[src=php]<?php
/* Die XMLRPC-Schnittstelle komplett abschalten */
add_filter( 'xmlrpc_enabled', '__return_false' );
/* Den HTTP-Header vom XMLRPC-Eintrag bereinigen */
add_filter( 'wp_headers', 'AH_remove_x_pingback' );
function AH_remove_x_pingback( $headers )
{
unset( $headers['X-Pingback'] );
return $headers;
}[/src]

Wichtiger ist folgender Schritt: den Zugriff über .htaccess blockieren.

[src=apache]#XML-RPC Schnittstelle abschalten
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>[/src]

Online Tests

Security Scanner: Hacker Target
Geschwindigkeit: Pingdom
Geschwindigkeit (strenger): PageSpeed Insights
Geschwindigkeit (teils komische Kriterien, wie CDN): GTmetrix
Mobilgeräte: Google Mobile Friendly
 
Zuletzt bearbeitet:

LadyRavenous

in Schwarz
Teammitglied

Registriert
26 Dez. 2016
Beiträge
16.080
Ort
hello world
  • Thread Starter Thread Starter
  • #2
Geschwindigkeitsoptimierung

Geschwindigkeit habe ich euch schon in der .htaccess ein wenig mitgebracht. Wer einen der oberen Tests besucht, wird schnell merken, wo Probleme sind und dann fängt das Optimieren an. Das lustigste Ergebnis, was ich zuletzt gesehen habe, waren 0 von 100 Punkte bei Googles PageSpeed Insights, was zu einem schönem Gelächter ringsherum geführt hat. Nachdem auch immer mehr von Smartphones aus gesurft und gelesen wird, sollte man auch darauf achten, dass man den Inhalt am Smartphone auch gut lesen kann. Zusätzlich ist möglichst schnelles Laden praktisch, wenn die Netzabdeckung nicht so gut ist (reicht ja in der U-Bahn zwischen zwei Stationen zu sitzen).
Zwei gute Grundlagen sind ein schlankes Theme und ein guter Hoster, aber egal wie lässt sich immer noch etwas herausholen.

1. Schritt Bestandsaufnahme

Tests anschmeißen, Popcorn oder Chips holen und gespannt warten, was die Tests ergeben.
Pingdom Tools zeigen gut, was wann geladen wird und wo ggf. Probleme stecken.
Googles PageSpeed Insights ist gnadenloser. Über 90 Punkte sind gefühlt ein gutes, akzeptables Ergebnis.
GTmatrix hat meiner Meinung nach einige komische Bewertungskriterien, dafür findet es auch doppelte Skripte und ähnliche Kuriositäten, die suboptimal sind.

2. Schritt Verbesserungen überlegen

Es kann nur besser werden ;)
Wenn Änderungen nötig sind, die ins Theme greifen, am besten ein Backup und dann ein Childtheme erstellen (oder daran verzweifeln und mit einer Pulle Bier zu Schritt 3 weiterschreiten).

3. Schritt Backup erstellen

Sicher ist sicher! Diesmal mit Childtheme.

4. Schritt Verbesserungen

Hands-on

5. Schritt kontrollieren

Ergebnis mit den Tests kontrollieren und ggf. zurück zu Schritt 2 oder 4.


Caching

Die größte Verbesserung sollten Caching und Komprimierung von Dateien in .htaccess bringen. Caching per Plugin ergibt ein paar zusätzliche Punkte.

Optimierung von Javascript und CSS

Der nächste Punkt dürften Javascript und CSS optimieren sein. Als erstes habe ich JavaScript-Dateien in den Footer geschoben (Ergänzung in functions.php).

[src=php]function evolution_print_jquery_in_footer() {
if ( ! is_admin() )
remove_action('wp_head', 'wp_print_scripts');
remove_action('wp_head', 'wp_print_head_scripts', 9);
remove_action('wp_head', 'wp_enqueue_scripts', 1);
}[/src]

Wer will, kann zudem Komprimierungs-Plugins ausprobieren. Diese komprimieren JS und CSS zusätzlich.

Ein Kuriosium, was ich vor kurzem sah: @import CSS. @import CSS soll nicht mehr verwendet werden, da es beim Laden andere Ressourcen blockieren kann, was das im Theme wohl auch tat.

Above the fold: die Teile von CSS und JS nach unten in den Footer verschieben, die nicht ohne Scrollen benötigt werden. Joa, lösbar, hat aber bei mir nichts gebracht.

Query Strings von statischen Dateien entfernen (functions.php im Theme):

[src=php]function _remove_script_version( $src ){
$parts = explode( '?ver', $src );
return $parts[0];
}
add_filter( 'script_loader_src', '_remove_script_version', 15, 1 );
add_filter( 'style_loader_src', '_remove_script_version', 15, 1 );[/src]

Bilder

Häufig auch ein Punkt, der Verbesserung benötigt: Bilder. PageSpeed Insights zeigt auch gut, welches Bild um wieviel zu groß ist.
  • Bilder verkleinern (Qualität und Größe) für schnelleres Laden
  • Dazu gibts auch ein Plugin WP Smush, was Bilder automatisch optimiert (für faule Säcke).
  • In functions.php kann man, wenn man spezielle Größen verwenden möchte, zusätzliche Bildergrößen vordefinieren und anschließend beim Einfügen von Bildern in Beiträgen verwenden.

Größe hinzufügen:

[src=php]add_image_size( 'insta-image', 75, 75 );[/src]

Externe Quellen

Google-Schriftarten müssen auch noch nicht im Header geladen werden, hier am Beispiel des Themes Baskerville.

[src=php]function theme_remove_scripts() {
wp_deregister_style( 'baskerville_googleFonts' );
wp_dequeue_script( 'baskerville_googleFonts' );
}
add_action( 'wp_print_styles', 'theme_remove_scripts', 20 );[/src]

Ein weiteres Mittel bei externen Quellen ist Prefetching im Header, wie hier am Beispiel von Google Fonts:

[src=html4strict] <link rel="dns-prefetch" href="//fonts.googleapis.com">[/src]

Gravatar gibt Kommentaren eine persönliche Note, aber schlägt sich ebenfalls auf die Geschwindigkeit nieder. DNS-Lookups reduzieren hilft ebenfalls, hier kommt es drauf an, was man alles anfragt. Hotlinking kann man zudem auch verbieten, damit andere nicht deine Bandbreite "klauen":

[src=apache]RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?deinedomain.de [NC]
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?google.com [NC]
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?feed.de/deinedomain [NC]
RewriteRule \.(jpg|jpeg|png|gif)$ – [NC,F,L][/src]

In manchen Fällen kann Hotlinking trotzdem auch gewünscht sein, entscheide selbst, ob du das willst oder nicht. URLs müssen natürlich noch angepasst werden.

Plugins

Schlecht programmierte Plugins können definitiv auch die Geschwindigkeit beeinträchtigen. Wie ausprobieren? Über SFTP einzelnes Plugin umbenennen und nochmals ausprobieren. Irgendwann hat man die Quelle gefunden.
Auch hier gilt: weniger ist mehr.

Datenbank

Ein Faktor bei der Geschwindigkeit der Site ist die Datenbank. Wenn man häufig Beiträge editiert, wächst die Größe der Datenbank schnell an. Dies kann man mit zwei Zeilen in
wp-config.php ändern. Die erste setzt das Interval vom automatischen Zwischenspeichern auf 300, die zweite begrenzt die Anzahl der gespeicherten Versionen auf 10.

[src=php]define('AUTOSAVE_INTERVAL', 300); // seconds
define('WP_POST_REVISIONS', 10);[/src]

Pingbacks und Trackbacks werden noch gerne genutzt, können aber auch die Größe und Geschwindigkeit beeinträchtigen.

Ansonsten gelten die üblichen MySQL/was auch immer du an DB verwendest-Optimierungen.

PHP

Einige Hoster bieten weiterhin PHP 5 an, aber PHP 7 ist durchschnittlich schneller.
 
Zuletzt bearbeitet:

dexter

Cloogshicer®
Teammitglied

Registriert
14 Juli 2013
Beiträge
5.320
Schöne Zusammenfassung, anderthalb Anmerkungen:
Unnötige Plugins gehören entfernt, um die Angriffsfläche zu verringern. Deaktivieren reicht übrigens nicht!
Weil? Ich kenne keinen Fall, wo deaktivierte kaputte Plugins Probleme gemacht hätten.
Sind größere Anpassungen nötig, damit ihr zufrieden seid, könnt ihr entweder im Theme selbst schreiben (und dann nicht mehr updaten, da sonst die Änderungen alle weg sind) oder ein Child-Theme anlegen. Letzteres hat bei mir nie so wirklich geklappt.
Standard-Themes sind schon fett* und voll mit Müll. Child-theme erhöhen die Komplexität zusätzlich erheblich, braucht imho kein Mensch. Was die Sicherheit betrifft, keine Ahnung, aber noch mehr Komplexität machts sicher nicht besser.

Verwende möglichst nicht den Benutzernamen admin
Wenn ich mich recht entsinne, ist seit etlichen Versionen nicht mehr möglich, admin zu verwenden. Mag grad nich nachschauen ;)

* Mal ein Theme von mir, noch Verbesserungsmöglichkeiten drin, aber nahezu frei von Redundanzen, wo man bei twenty-x & Co auch als Profi nicht durchschaut:
[src=php]<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de" lang="de">
<head profile="http://gmpg.org/xfn/11">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<meta name="viewport" content="width=device-width" />
<title><?php bloginfo('name'); ?> | <?php if( is_home() ) : echo bloginfo( 'description' ); endif; ?><?php wp_title( '', true ); ?></title>
<link rel="pingback" href="<?php bloginfo( 'pingback_url' ); ?>" />
<style type="text/css">@import url("<?php bloginfo('stylesheet_url'); ?>");</style>
<?php wp_head(); ?>
</head>
<body>
<h1><a href="<?php echo esc_url( home_url( '/' ) ); ?>" title="<?php echo esc_attr( get_bloginfo( 'name', 'display' ) ); ?>" rel="home"><?php bloginfo( 'name' ); ?> <span><?php echo get_bloginfo( 'description' ); ?></span></a></h1>
<ul id="sidebar"><?php if ( !function_exists('dynamic_sidebar') || !dynamic_sidebar() ) : endif; ?></ul>
<?php if( is_home() || is_archive() || is_single) {if ( have_posts() ) : while ( have_posts() ) : the_post(); ?>
<h2><a href="<?php the_permalink(); ?>" title="<?php the_title(); ?>"><?php the_title() ?></a></h2>
<?php the_content(); ?>
<div class="metadata"> <a href="<?php the_permalink() ?>">mehr ...</a> Geschrieben am <?php the_time('j. F Y'); ?> in <?php echo get_the_category_list(); ?> - <?php comments_popup_link( __( 'Schreibe den ersten Kommentar', 'break' ), __( 'bisher 1 Kommentar', 'break' ), __( 'bisher % Kommentare', 'break' ) ); ?> <?php edit_post_link('Bearbeiten',' | ',''); ?></div>
<?php endwhile; else : ?>
<div class="post error"><h2 class="404">Oha, da is irgendwas kaputt!</h2></div>
<?php endif; }if( is_single() || is_page() ); if (comments_open() || '0' != get_comments_number() )comments_template( '', true ); ?>
</body>
</html>[/src]
(ja, das ist ein komplettes WP-Theme, noch ne functions.php für dynamische Sidebar etc. dazu falls gewünscht, fertig.)
 

LadyRavenous

in Schwarz
Teammitglied

Registriert
26 Dez. 2016
Beiträge
16.080
Ort
hello world
  • Thread Starter Thread Starter
  • #4
Der Code ist zumindest noch da, wenn man das Plugin nicht deinstalliert. Code kann ausgeführt werden.

admin ging zuletzt (vor wenigen Monaten) bei mir noch, daher die Bemerkung. Wenn sich es seitdem geändert hat, dann gut.

Jupp, die meisten Themes sind Monster, manche mehr als andere. Von einem von mir verwendeten Theme habe ich mir gerade die Änderungen angeschaut, die ich nicht eingespielt habe. Nö, glaub das will ich auch beim besten Willen nicht.
Dein Theme muss ich mir mal genauer anschauen, das klingt interessant! Schön schlank. functions.php schreiben sollt kein Thema sein.
 
Zuletzt bearbeitet:

LadyRavenous

in Schwarz
Teammitglied

Registriert
26 Dez. 2016
Beiträge
16.080
Ort
hello world
  • Thread Starter Thread Starter
  • #5
Aus gegebenen Anlass (...), nachdem meine Weiterleitung nach dem letzten Update weg war, möchte ich darauf hinweisen, dass Wordpress standardmäßig mit der Berechtigung 0644 alles zwischen #BEGIN WordPress und #END WordPress ändern kann. Das sollte normalerweise in etwa so aussehen:

[src=apache]# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress[/src]

Mein Fehler war, dass ich zwar alles andere außerhalb hatte, aber eben nicht die Weiterleitung.
Falls man andere Permalinks setzt als Wordpress, können diese also durch ein Update überschrieben werden.
Was man gegen die Modifizierungen durch Wordpress (und Plugins) machen kann?

1. Alle anderen Regeln außerhalb setzen

Das ist denke ich die einfachste Variante, die für die meisten Fälle ausreichen sollte. Einfach alle anderen Regeln außerhalb der beiden Kommentare setzen und schon modifiziert Wordpress diese Regeln nicht.

Vorteil: einfach, für die meisten Fälle ausreichend
Nachteil: falls man Permalinks ändern möchte, werden sie regelmäßig überschrieben. Wenige schlechte Plugins schreiben ebenfalls in den Regeln.

2. Berechtigung ändern

Durch die Berechtigung 444, 440 oder 400 kann Wordpress (und Plugins) nicht mehr in der .htaccess schreiben. Leider hat man den Nachteil, dass man, wenn man dort häufiger was ändert, auch selbst länger braucht.

Vorteil: nachhaltig, auf Dateiebene gelöst
Nachteil: selbst wird man auch eingeschränkt und braucht länger für Änderungen, man muss die Berechtigung wieder ändern, falls sich etwas an der Zusammensetzung der Permalinks ändert (was selten der Fall ist)

3. Über das Theme Wordpress verbieten, Änderungen vorzunehmen

Eine witzige Variante ist es, Wordpress über das Theme einzuschränken, indem man die folgenden Zeilen in functions.php einfügt:

[src=php]// Stop WordPress from modifying .htaccess permalink rules
add_filter('flush_rewrite_rules_hard','__return_false');[/src]

Vorteil: Wordpress kann nicht mehr schreiben, man selbst kann weiter frickeln
Nachteil: Theme kann sich ändern (außer man hat diese Updates abgeschalten), man muss diesen Filter auskommentieren, falls sich etwas an der Zusammensetzung der Permalinks ändert (was selten der Fall ist)

4. nix machen

Wer nichts an .htaccess geändert hat und es nicht vorhat, braucht sich keinen Kopf machen ;)
 

nocopy

Neu angemeldet

Registriert
12 Dez. 2017
Beiträge
4
Ort
Canada
Um meine WordPress-Installation abzusichern, habe ich mich u.a. dazu entschieden das Plugin "Simply Static" zu verwenden. Meine WordPress-Installation wird nun statisch statt dynamisch ausgeliefert.
 

dexter

Cloogshicer®
Teammitglied

Registriert
14 Juli 2013
Beiträge
5.320
Ohne Absicherung von WP selbst, bringt die das Plugin äusserst wenig Mehrwert in Punkto Sicherheit.
 

nocopy

Neu angemeldet

Registriert
12 Dez. 2017
Beiträge
4
Ort
Canada
Ohne Absicherung von WP selbst, bringt die das Plugin äusserst wenig Mehrwert in Punkto Sicherheit.

Könntest du das ausführlicher erklären? Die Root-Domain bietet dir nur den Zugriff auf die WordPress-Installation mit statischen HTML-Seiten. Die ursprüngliche WordPress-Installtion ist aus dem Internet nicht erreichbar, außer ich ändere den Pfad in meiner nginx-Konfigurationsdatei. Des Weiteren nehmen wir an, dass es sich um eine Basis-Installation (ohne Plugins) handelt und dass keine Regestrierungen möglich als auch keine Dienster Dritter eingebunden sind.

Ich bin der Auffassung, dass eine derartige Situation einen Angreifer nur wenig Angriffsfläche bietet.

Kann man ja mal konstruktiv diskutieren :-)
 

dexter

Cloogshicer®
Teammitglied

Registriert
14 Juli 2013
Beiträge
5.320
Könntest du das ausführlicher erklären?
Nöö, das hast Du ja jetzt nachgeholt.
Wegen der Registrierung: das ist kein limitierendes Element, da die Registrierung in dem von Dir beschriebenen Fall eh nicht erreichbar ist.
 
Oben