WordPress Security-Maßnahmen erweitern

Immer wieder stoße ich bei Kunden auf WordPress Installationen, die überhaupt keine Sicherheitsmaßnahmen erfahren haben. Vor einiger Zeit habe ich einen umfassenden Artikel veröffentlicht, der die wichtigsten Security-Maßnahmen abdeckt. In der Zwischenzeit habe ich noch einige weitere Möglichkeiten entdeckt, die eigene WordPress-Seite (und durchaus auch andere Webseiten) abzusichern. (Aktualisiert am 01.02.2016). erweiterte-wordpress-security

Können Webseiten 100% sicher sein?

Achtung: Es wird bei den folgenden Maßnahmen sicher wieder den einen oder anderen Leser geben, der diese infrage stellt. Ich möchte daher gleich hier auf Folgendes aufmerksam machen: Alle Maßnahmen, die in vernünftigem, wirtschaftlichem Umfang von normalen Webseitenbetreibern getroffen werden können, stellen niemals eine 100%-ige Sicherheit dar. Ist ein Profi am Werk, ist es unglaublich schwer, ein System wasserdicht abzusichern. Sicherheitslücken verstecken sich nicht nur in Webseiten, sondern können auch vom Webhoster unfreiwillig geliefert werden. Die hier gelisteten Maßnahmen machen es aber den allerhäufigsten Angreifern schwer: Script-Kiddies und automatisch agierende Botsysteme, die systematisch Sicherheitslücken suchen um Schadsoftware oder SPAM-Mails zu verteilen.

Verzeichnisrechte massiv einschränken

Die aufwändigste und extremste Variante der Absicherung einer Seite, ist meiner Ansicht nach die Entfernung von ALLEN Schreibrechten auf Ordner und Dateien, wo es nur möglich ist. Wenn selbst der Webserver keine Schreibrechte hat, ist es für Angreifer deutlich schwerer Scripts auf den Webserver hochzuladen. Meine Empfehlung für Hardcore-User: Schreibrechte nur auf die folgenden Ordner und Dateien geben

  • upload-Ordner in wp-content
  • Bestimmte Ordner von Caching-Plugins
  • Sitemap-Files

ALLE anderen Ordner und Dateien kommen für den Betrieb einer WordPress-Seite ohne Schreibrechte aus, da sie ja nur geöffnet und gelesen werden müssen vom Webserver. Der Nachteil: Bei Änderungen am Theme oder der wp-config.php, der .htaccess oder aber auch an Plugins (Updates, Installationen, Löschungen, etc.) müssen die Rechte vorrübergehend wieder gelockert werden (Achtung: upgrade-Ordner bei Updates nicht vergessen). Das halte ich für einen vertretbaren Aufwand verglichen mit dem Plus an Sicherheit.

PHP Ausführung in Upload Ordner verhindern

Da man dem Webserver nicht die Schreibrechte im Upload-Ordner nehmen kann, ist dieser Ordner besonders gefährdet. Daher macht es Sinn, in diesem Ordner (und allen Unterordnern) die Ausführung von PHP zu verhindern. Am einfachsten geht das mit dem folgenden Befehl in einer .htaccess Datei im Upload-Ordner

<Files *.php>
Deny from All
</Files>

Das gleiche kann man übrigens auch mit Pearl-Scripts machen:

<Files *.pl>
Deny from All
</Files>

Uploads dieser Dateien sind somit wirkungslos. In folgenden Ordnern macht es ebenfalls Sinn die Ausführung von PHP und Pearl Skripten zu verhindern:

  • wp-content (Achtung: manche Plugins machen das nicht mit)
  • wp-includes

Schreibrechte von .htaccess-Dateien entfernen

Wenn man nicht generell Schreibrechte entfernen möchte, sollte man zumindest den wichtigsten Dateien die Schreibrechte nehmen. Bei der wp-config.php ist das klar. Die .htaccess vergessen viele. Dabei werden auch diese Files des öfteren kompromittiert, so dass zum Beispiel automatische Weiterleitungen der eigenen Webseite auf Virenschleudern stattfinden. Von daher sollte man von .htaccess Dateien die Schreibrechte entfernen.

Loginbereich in WordPress verstecken

Gerade der Login von WordPress wird häufig angegriffen um Adminzugänge zu hacken. Neben einem Plugin, welches Loginversuche blockt wenn diese zu häufig geschehen, kann man auch den Loginbereich verstecken. Ein Plugin, welches dafür gut geeignet ist, ist Stealth Login Page.

WordPress Login per SSL absichern

Nicht nur Sicherheitslücken der Webseite sind ein Problem. Was, wenn das eigene Heimnetzwerk oder WLAN ausspioniert wird und Passwörter „mitgehört“ werden? Das passiert durchaus häufiger. Eingegebene Passwörter in Login-Formulare, die nicht SSL verschlüsselt sind, sind im Klartext mit Network-Sniffern lesbar. Um das zu verhindern kann man den Login oder auch den kompletten Adminbereich in WordPress per SSL verschlüsseln. Das geht mit Hilfe eines SSL Zertifikats und folgendem Code in der wp-config.php.

//for just the login
define('FORCE_SSL_LOGIN', true);
//for the whole admin
define('FORCE_SSL_ADMIN', true);

Bestimmte Dateiformen sperren

Es gibt Dateien, die Infos über die Version von WordPress und Plugins verraten. Zum Beispiel liesmich.html oder Textdateien. Diese müssen nicht geöffnet werden können. Daher nimmt man ihnen am besten die Leseberechtigung. So vermeidet man es auch, diese Dateien löschen zu müssen. Durch Updates und Neuinstallation kann das ziemlich lästig sein.

Options All -Indexes
<files readme.html>
Order allow,deny
Deny from all
</files>
<files *.sql>
Order allow,deny
Deny from all
</files>
<files *.zip>
Order allow,deny
Deny from all
</files>
<files liesmich.html>
Order allow,deny
Deny from all
</files>
<files .htaccess>
order allow,deny
deny from all
</files>
<files *.txt>
Order allow,deny
Deny from all
</files>
<files license.txt>
Order allow,deny
Deny from all
</files>
<files error_log>
Order allow,deny
Deny from all
</files>

WordPress Version verstecken

Zudem kann man verhindern, dass die WordPress-Version im Header der Seite ausgegeben wird. Folgender Befehl gehört in die functions.php

function wpbeginner_remove_version() {
return '';
}
add_filter('the_generator', 'wpbeginner_remove_version');

Server-Signatur deaktivieren

Ganz paranoide können auch Infos über den Webserver deaktivieren. Folgender Befehl gehört in die .htaccess

ServerSignature Off

SQL Injections verhindern

Gerne werden auch Codes in die WordPress-Datenbank geschleust. Das passiert über ungesicherte Formulare oder alte und unsichere Plugins. Der folgende .htaccess Block verhindert einige SQL Injections (ggfs. können diese Anweisungen Probleme bei normaler Funktionalität verursachen):

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_METHOD} ^(HEAD|TRACE|DELETE|TRACK) [NC]
RewriteRule ^(.*)$ - [F,L]
RewriteCond %{QUERY_STRING} \.\.\/ [NC,OR]
RewriteCond %{QUERY_STRING} boot\.ini [NC,OR]
RewriteCond %{QUERY_STRING} tag\= [NC,OR]
RewriteCond %{QUERY_STRING} ftp\: [NC,OR]
RewriteCond %{QUERY_STRING} http\: [NC,OR]
RewriteCond %{QUERY_STRING} https\: [NC,OR]
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|%3D) [NC,OR]
RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(\[|\]|\(|\)|<|>|ê|"|;|\?|\*|=$).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(&#x22;|&#x27;|&#x3C;|&#x3E;|&#x5C;|&#x7B;|&#x7C;).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(%24&x).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(%0|%A|%B|%C|%D|%E|%F|127\.0).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(globals|encode|localhost|loopback).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(request|select|insert|union|declare|drop).* [NC]
RewriteCond %{HTTP_COOKIE} !^.*wordpress_logged_in_.*$
RewriteRule ^(.*)$ - [F,L]
</IfModule>

Überwachen von WordPress

Es gibt Möglichkeiten Eindringlinge auf einem Webserver zu erkennen. Richtige Profis verwischen ihre Spuren. Aber die meisten legen ihre PHP Dateien ab und scheren sich nicht darum. Es gibt Shell-Befehle, mit denen man auf einem Linux Server seine Webseite nach geänderten Dateien durchsuchen kann. Die, die einem komisch vorkommen, sollte man prüfen. Diese Überwachung baut man am besten in eine .sh Datei, die per Cronjob einmal täglich ausgeführt wird und das Ergebnis an eine Email-Adresse schickt. Haben Sie nämlich einen Eindringling, der auf Ihrer Webseite Malware verteilt, WOLLEN Sie das schnellstmöglich wissen. Bekommt Google nämlich Wind davon, kann es Ihnen passieren, dass Ihre Seite deindexiert wird. Unter Umständen der absolute Super-GAU.

Suchen nach geänderten Dateien

Der folgende Befehl sucht nach PHP-Dateien, die in den letzten 24 Stunden geändert wurden und schreibt das Ergebnis in eine Temp-Datei.

find /absolutepath/towebsite/public_html -mtime -1 -name "*.php" -printf '%TY-%Tm-%Td %TT\t%p\n' >> file.tmp

Das Gleiche macht man mit .js Dateien (und evtl. auch mit .pl Dateien)

Suche nach verdächtigem Code in PHP Dateien

Eindringlinge schleusen auch gerne bösartigen Code in wichtige PHP Dateien, wie die index.php. Sie können zum Beispiel alle in den letzten Tagen geänderten PHP Files auf bestimmten Code durchsuchen.

find /absolutepath/towebsite/public_html -mtime -7 -name "*.php" | xargs grep -l -i "eval\|base64_decode\|iframe\|pharma\|viagra\|file_get_contents" >> file.tmp

Den Upload Ordner von WordPress nach PHP Dateien durchsuchen

PHP Files haben im Upload-Ordner nichts zu suchen. Daher sucht man am besten täglich danach um Einbrüche zu erkennen.

find /absolutepath/towebsite/public_html/wp-content/uploads -name "*.php" -print >> file.tmp

Datei- und Verzeichnisrechte im Auge behalten

Wenn man viel an seiner Webseite ändert, sollte man die Rechte im Auge behalten. Ordner, die mit 777 offen wie ein Scheunentor sind, sollte man schleunigst schließen. Da das sehr anstrengend sein kann, macht man das am besten automatisiert. Folgende Abfragen durchsuchen alle Files und Ordner und geben die aus, die evtl. eine zu lockere Sicherheit aufweisen. Achtung: die hier angegebenen Werte müssen an die jeweilige Webserver und Benutzerrecht-Umgebung angepasst werden. Auf 777 sollte man allerdings immer prüfen.

find /home -type d -perm 0777 >> file.tmp
find /home -type f -perm 0777 >> file.tmp
find /home -type d -perm 0007 >> file.tmp
find /home -type f -perm 0007 >> file.tmp
find /home -type d -perm 0407 >> file.tmp
find /home -type f -perm 0407 >> file.tmp
find /home -type d -perm 0607 >> file.tmp
find /home -type f -perm 0607 >> file.tmp
find /home -type d -perm 0707 >> file.tmp
find /home -type f -perm 0707 >> file.tmp
find /home -type d -perm 0747 >> file.tmp
find /home -type f -perm 0747 >> file.tmp
find /home -type d -perm 0767 >> file.tmp
find /home -type f -perm 0767 >> file.tmp
find /home -type d -perm 0757 >> file.tmp
find /home -type f -perm 0757 >> file.tmp
find /home -type d -perm 0557 >> file.tmp
find /home -type f -perm 0557 >> file.tmp
find /home -type d -perm 0577 >> file.tmp
find /home -type f -perm 0577 >> file.tmp
find /home -type d -perm 0177 >> file.tmp
find /home -type f -perm 0177 >> file.tmp
find /home -type d -perm 0077 >> file.tmp
find /home -type f -perm 0077 >> file.tmp

Verschicken der Ergebnisse per Email

Die Ergebnisse verschickt man dann zum Beispiel über den Befehl

mailx -s "Webserver File-Changes" email@tome.de <file.tmp

Prüfen, ob eine WordPress Seite bereits gehackt wurde

Es gibt Anbieter wie Sucuri, die die eigene Webseite auf Malware, bösartigen Code, SPAM, Blacklisteinträge, etc. testen können. Eine Seite, die bereits verseucht ist, kann man absichern wie man will. Bevor man also die hier gelisteten Maßnahmen betreibt, sollte man erstmal checken, ob die WordPress Webseite zum aktuellen Zeitpunkt noch sauber ist. Sonst ist eine Neuinstallation ggfs. vorab nötig. Noch besser als der Online Scanner von Sucuri, ist das Plugin für WordPress. Es testet nicht nur das Theme und die WordPress Core Files auf Schadcode und Veränderungen? Es gibt dem Seitenbetreiber auch die Chance eine Web Application Firewall einzurichten, die letzten veränderten Dateien anzuzeigen, sowie die uploads-, wp-content- und wp-includes-Ordner vor direktem PHP Zugriff zu schützen. Ein extrem guter Helfer vor und nach dem Hack.

Absoluten Pfad verstecken

Achtung: Kommt bei Sucuri eine Warnung bezüglich eines offenen absoluten Pfades, ist dieser scheinbar relativ einfach auslesbar. Von daher sollte man in der .htaccess mit folgendem Befehl die Ausgabe von Fehlern unterbinden, die den absoluten Server-Pfad Ihrer WordPress-Installation mitgeben:

php_flag display_errors off

Zugriffe auf XML-RPC abstellen

Die XML-RPC-Schnittstelle ist dafür da, 3rd Party Programme oder Geräte mit WordPress zusammenarbeiten zu lassen. Meistens benötigt man das nicht, außer man möchte von Unterwegs per iPad etc. mit WordPress arbeiten oder möchte nicht auf TrackBack-Benachrichtigungen verzichten. Die Datei xmlrpc.php im WordPress Root Verzeichnis ist häufiger Angriffspunkt für DDOS-Attacken. Man kann den Zugriff entweder auf Serverebene deaktivieren oder tut dies in der .htaccess-Datei im root-Verzeichnis der WordPress-Installation.

<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>

Einsetzen der 6G Blacklist

Die 6G Blacklist ist eine Sammlung von einfachen, aber wirksamen .htaccess-Direktiven, die auf Serverebene verdächtige Anfragen blockiert. Dadurch werden Ressourcen für PHP und MySQL gespart. Kann auch auf Nicht-WordPress-Webseiten eingesetzt werden. Diese Direktiven am besten in der .htaccess-Datei vor den WordPress-Permalink-Direktiven einführen. Man kann testen, ob die Firewall greift, indem man eine beliebige Seite der eigenen Webseite mit dem Zusatz „?eval(“ öffnet. Zum Beispiel:

http://www.meinedomain.de/?eval( 

öffnet. Kommt dann eine „Forbidden“ Meldung, greift die Firewall.

# 6G FIREWALL/BLACKLIST
# @ https://perishablepress.com/6g/

# 6G:[QUERY STRINGS]

	RewriteEngine On
	RewriteCond %{QUERY_STRING} (eval\() [NC,OR]
	RewriteCond %{QUERY_STRING} (127\.0\.0\.1) [NC,OR]
	RewriteCond %{QUERY_STRING} ([a-z0-9]{2000}) [NC,OR]
	RewriteCond %{QUERY_STRING} (javascript:)(.*)(;) [NC,OR]
	RewriteCond %{QUERY_STRING} (base64_encode)(.*)(\() [NC,OR]
	RewriteCond %{QUERY_STRING} (GLOBALS|REQUEST)(=|\[|%) [NC,OR]
	RewriteCond %{QUERY_STRING} (<|%3C)(.*)script(.*)(>|%3) [NC,OR]
	RewriteCond %{QUERY_STRING} (\\|\.\.\.|\.\./|~|`|<|>|\|) [NC,OR]
	RewriteCond %{QUERY_STRING} (boot\.ini|etc/passwd|self/environ) [NC,OR]
	RewriteCond %{QUERY_STRING} (thumbs?(_editor|open)?|tim(thumb)?)\.php [NC,OR]
	RewriteCond %{QUERY_STRING} (\'|\")(.*)(drop|insert|md5|select|union) [NC]
	RewriteRule .* - [F]


# 6G:[REQUEST METHOD]

	RewriteCond %{REQUEST_METHOD} ^(connect|debug|delete|move|put|trace|track) [NC]
	RewriteRule .* - [F]


# 6G:[REFERRERS]

	RewriteCond %{HTTP_REFERER} ([a-z0-9]{2000}) [NC,OR]
	RewriteCond %{HTTP_REFERER} (semalt.com|todaperfeita) [NC]
	RewriteRule .* - [F]


# 6G:[REQUEST STRINGS]

	RedirectMatch 403 (?i)([a-z0-9]{2000})
	RedirectMatch 403 (?i)(https?|ftp|php):/
	RedirectMatch 403 (?i)(base64_encode)(.*)(\()
	RedirectMatch 403 (?i)(=\\\'|=\\%27|/\\\'/?)\.
	RedirectMatch 403 (?i)/(\$(\&)?|\*|\"|\.|,|&|&?)/?$
	RedirectMatch 403 (?i)(\{0\}|\(/\(|\.\.\.|\+\+\+|\\\"\\\")
	RedirectMatch 403 (?i)(~|`|<|>|:|;|,|%|\\|\s|\{|\}|\[|\]|\|)
	RedirectMatch 403 (?i)/(=|\$&|_mm|cgi-|etc/passwd|muieblack)
	RedirectMatch 403 (?i)(&pws=0|_vti_|\(null\)|\{\$itemURL\}|echo(.*)kae|etc/passwd|eval\(|self/environ)
	RedirectMatch 403 (?i)\.(aspx?|bash|bak?|cfg|cgi|dll|exe|git|hg|ini|jsp|log|mdb|out|sql|svn|swp|tar|rar|rdf)$
	RedirectMatch 403 (?i)/(^$|(wp-)?config|mobiquo|phpinfo|shell|sqlpatch|thumb|thumb_editor|thumbopen|timthumb|webshell)\.php


# 6G:[USER AGENTS]

	SetEnvIfNoCase User-Agent ([a-z0-9]{2000}) bad_bot
	SetEnvIfNoCase User-Agent (archive.org|binlar|casper|checkpriv|choppy|clshttp|cmsworld|diavol|dotbot|extract|feedfinder|flicky|g00g1e|harvest|heritrix|httrack|kmccrew|loader|miner|nikto|nutch|planetwork|postrank|purebot|pycurl|python|seekerspider|siclab|skygrid|sqlmap|sucker|turnit|vikspider|winhttp|xxxyy|youda|zmeu|zune) bad_bot
	
		Order Allow,Deny
		Allow from All
		Deny from env=bad_bot
	


# 6G:[BAD IPS]

	Order Allow,Deny
	Allow from All
	# uncomment/edit/repeat next line to block IPs
	# Deny from 123.456.789

Fazit: Je mehr Maßnahmen getroffen werden, die es Angreifern erschweren, Infos über WordPress-Installationen oder Zugänge zu diesen zu erhalten, desto besser. Security by Oscurity wird von manchem in Frage gestellt, weil es Profihacker nicht gänzlich behindert. Ich sehe das anders und vergleiche gerne mit Häusern: Nur weil ein Einbrecher auch eine Fensterscheibe einschlagen könnte um in ein Haus einzubrechen, lässt man nicht die Haustür sperrangelweit offen. Und brauchen Sie Hilfe um Ihre Webseite abzusichern oder Ihre Webseite wurde gehackt? Wir helfen gerne.

46 Kommentare

  1. Lukas sagt:

    Klasse Artikel. Für einen Anfänger ist das Thema sehr unübersichtlich und verwirrend aber so versteht man doch schon mehr.
    Vielen Dank 🙂

  2. Dirk sagt:

    Hallo,

    tolle Tipps.
    Aber wenn man diesen hier nimmt:
    WordPress Login per SSL absichern

    Und man aber bereits ein SSL-Zertifikat hat, muss man doch nicht zusätzlich das in die .htaccess schreiben oder?

    //for just the login
    define(‚FORCE_SSL_LOGIN‘, true);
    //for the whole admin
    define(‚FORCE_SSL_ADMIN‘, true);

    Weil das Zertfikat ja das Backend beim Einloggen mit absichert?

  3. Dirk sagt:

    Hallo Leute,

    ein Klasse Beitrag, ich muss aber mal fragen, wo kommen diese Dinge immer hin.

    Vor dem # BEGIN WordPress oder # END WordPress

    Danke Euch für einen Tipp.

    LG
    Dirk

  4. Frank Tisch sagt:

    Ich hab ganz gute Erfahrungen mit iThemes Security gemacht, oder wie es früher hieß: Better Wp Security. Bis jetzt hat das Plugin gute Dienste geleistet.

  5. Janina sagt:

    Hallo,

    Eine Frage: Lohnt es sich ein Sicherheits-Plugin wie z.B. Wordfence zu installieren? Oder bringen solche Plugins eher wenig?

    Mfg,
    Janina

  6. Sven sagt:

    Hi René,

    guter Artikel, vielen Dank.

    Ich kann ein Lied davon singen. Vor ca. 9 Monaten wurde einer meiner Webseiten tatsächlich Opfer eines Angriffs. Natürlich hatte ich auch noch den Klassiker: Kein Backup.

    Das passiert mir kein 2. Mal. Jetzt habe ich alle Seiten abgesichert.

    Grüße
    Sven

  7. Abnehmen sagt:

    Danke füe diese hilfreichen Tipps!

  8. Timoo sagt:

    Wieder ein dicker Batzen an nützlichen Security-Tipps, danke. Ich habe jetzt auch ein paar Sachen umgesetzt. Fühlt sich doch irgendwie besser an. 😉 Schade, dass man immernoch so viel händisch nachhelfen muss.

  9. Vielen Dank für die Security Tipps. Beste Grüße.

  10. Jochen sagt:

    Hallo Rene,
    super umfangreicher Artikel.
    Das „PHP Ausführung in Upload Ordner verhindern“ hab ich bei mir gleich mal umgesetzt.
    danke
    Jochen

  11. Andy sagt:

    Super, der Beitrag. Ich bin schon seit einiger Zeit dabei, den Blog sicherer zu machen. Ich möchte den Aufwand natürlich so gering, wie möglich halten, denke aber, dass hier sicherlich das eine oder andere dabei ist, was sich mit vertretbarem Aufwand umsetzen lässt. Was man natürlich auch nicht vergessen sollte, trotz aller Sicherheitsmassnahmen ist, dass man nach (zumindest jeder größeren) Änderung ein Backup seiner Seite und der Datenbank machen sollte.

  12. Vielen Dank für die wertvollen Tipps. Diese möchte ich soweit möglich auch umsetzen. Jetzt muss ich aber eine vermutlich dumme Frage stellen: „Was heißen Schreibrechte entfernen genau?“
    Das geschieht ja in der Regel mit einem FTP-Programm. Wäre die Einstellung 644 dann die richtige Wahl?

    • Das kann man so nicht beantworten, da es stark von der Konfiguration des Webservers abhängt. Bei 644 hat ja noch einer Rechte. Daher eher 444 für Files und 555 für Ordner.

  13. Mathias sagt:

    Hallo René,
    bin durch Zufall auf Deine Seite gestoßen und habe noch so einiges an nützlichen Security-Tipps gefunden. Vielen Dank!

    Vielleicht kannst Du mir einen Tipp bezüglich Dateiuploads geben?
    Ich möchte den Zugriff auf durch Benutzer hochgeladene Dateien beschränken, soll heißen, ich möchte den Zugriff auf diese Dateien nur für eine Usergruppe zulassen, von der diese Dateien hochgeladen worden sind. Ist Dir hier ein Plugin etc. bekannt, mit dem ich die Möglichkeit zum Dateiupload im Frontend habe und durch das diese Zugriffe automatisch gesetzt werden können?

    Vorab vielen Dank und frohes Werkeln an Deinem Blog.

    Mathias

  14. Martin sagt:

    Dieser Beitrag ist Supi.
    Bin gerade dabei mit eine .htaccess zu Basteln um meine Webseite Sicher zu machen.
    Ist es egal wo man das Eintrag in die .htaccess also vor dem # BEGIN WordPress oder kann es auch # END WordPress

    Auch würde mich interessieren ob meine auch jeweils eine .htaccess in folgende Ordner legt, das geht nämlich nicht 100% aus dem Beitrag hervor: Upload-Ordner und •wp-content und wp-includes.

    Und kennt jemand eine Seite wo ich diesen Tipp nachlesen könnte:Überwachen von WordPress erstellen einer .sh Datei und einbinden als Cron-Job und wo diese Datei abgelegt wird.

  15. Alex sagt:

    Gratulation – ein sehr gut gelungener Beitrag! Hier werden wirklich sehr viele Aspekte angesprochen. Außerdem dürften sich die Hinweise auch für WordPress Anfänger gut umsetzen lassen.

    Gefällt mir gut – ich werde den Beitrag gerne empfehlen, weiter so!

  16. Daniel Medic sagt:

    Sehr guter Blog

    Der Beitrag ließt sich gut und man stellt fest Mann lernt immer wieder dazu.

  17. Scheidenpilz sagt:

    Super Beitrag, vielen Dank für die guten Tipps.
    Arbeite auch schon seit über einem Jahr mit WordPress und da gibs wirklich immer wieder was neues hehe

Kommentar schreiben

* Notwendige Angaben

Netzgänger Webdesign | Schlehenweg 7 in Büchenbach | Bayern
Telefon: 0151/27051457 |
↑ oben
Inhalt