Ähnliche Beiträge
- WordPress mehrsprachig nutzen - ein Lösungsvorschlag
- Einschränken der Daten-typen im WordPress Upload
- Trenne Logik von der Ausgabe, mittels Hooks in WordPress
- Optionen aus WordPress an JavaScripts übergeben #1
- WordPress, WPCron und die richtige Zeit
- XML zu Array mit PHP
Journal
- Trend. Meiner.
- WordPress mehrsprachig nutzen – ein Lösungsvorschlag
- Besser die Wahrheit?
- Einschränken der Daten-typen im WordPress Upload
- Trenne Logik von der Ausgabe, mittels Hooks in WordPress
Projekte
Abonniere die neusten Artikel via Sidebar
ein-/ausblenden
Schütze deine wp-config.php
Anzeige
Ronald Huereca erklärt in einem Artikel auf Devlounge, wie man dafür sorgt, dass die wp-config.php der WordPress-Installation nicht für Hacker einfach erreichbar ist um so die Möglichkeit eines Hackerangriffs auf das eigene Blog zu erschweren.
Die wp-config.php ist der Schlüssel zur Datenbank und damit stehen einem Eindringen in die Datenbank nur wenige Handgriffe bevor und schon liegt die DB offen, Damit kann ein „Bösewicht“ die Daten verändern oder gar alle Daten löschen. Also liegt es nahe, diese Datei vor fremden Zugriff zu schützen. Wie und und mit welchen Mitteln man dies machen kann, das erklärt der Artikel auf zwei unterschiedliche Wegen.
Ich habe die jeweiligen Code-Schnippsel im Anschluss nochmal hinterlegt, da ich die Idee für sinnvoll und machbar, auch für den „Laien“, erachte, so dass man auch mit deutschen Sprachkenntnissen der Idee folgen und umsetzen kann.
.htaccess erweitern
Ronald erklärt zwei unterschiedliche Ansätze. Im ersten Schritt sichert er den Zugriff via .htaccess, was schnell und einfach erledigt ist.
# protect wpconfig.php
<files wp-config.php>
Order deny,allow
deny from all
</files>
Damit könnte eine .htaccess für WordPress folgenden Aufbau und Inhalt haben, wobei ich gleich einige mehr Regeln integriert habe, kleine Erläuterungen dazu im Syntax.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
# www2nowww
RewriteCond %{HTTP_HOST} ^([^.]+)\.bueltge\.de$ [NC]
RewriteRule ^(.*)$ http://bueltge.de/$1 [R=301,L]
# Hinzufuegn von Slash
RewriteCond %{REQUEST_URI} ^/[^\.]+[^/]$
RewriteRule ^(.*)$ http://%{HTTP_HOST}/$1/ [R=301,L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# Schutz der wp-config.php
<files wp-config.php>
Order deny,allow
deny from all
</files>
# Datei zum Regeln von IP-Bereichen
Order deny,allow
Allow from all
# Sperre folgende IPs
deny from 83.246.96.42
deny from 82.103.133.221
deny from 74.86.15.2
Auslagern der wp-config.php
Die zweite Idee geht davon aus, dass die Datei an einen Ort des Servers verschoben wird, der nicht öffentlich zugänglich ist. Ein Beispiel soll es verdeutlichen: die Datei liegt im Normalfall im absoluten Pfad /home/deinname/public_html/, dies ändert sich nun, denn die Datei wird eine Ebene tiefer abgelegt /home/deinname/. Dies ist nicht bei allen Webhostern so, so dass die Möglichkeit nicht bei allen WordPress-Installationen möglich ist.
Die klassische wp-config.php enthält folgenden Syntax.
<?php
// ** MySQL settings ** //
define('DB_NAME', 'wpbeta'); // The name of the database
define('DB_USER', 'root'); // Your MySQL username
define('DB_PASSWORD', ''); // ...and password
define('DB_HOST', 'localhost'); // 99% chance you won't need to change this value
define('DB_CHARSET', 'utf8');
define('DB_COLLATE', '');
// You can have multiple installations in one database if you give each a unique prefix
$table_prefix = 'wp_'; // Only numbers, letters, and underscores please!
// Change this to localize WordPress. A corresponding MO file for the
// chosen language must be installed to wp-content/languages.
// For example, install de.mo to wp-content/languages and set WPLANG to 'de'
// to enable German language support.
define ('WPLANG', 'de_DE');
/* That's all, stop editing! Happy blogging. */
define('ABSPATH', dirname(__FILE__).'/');
require_once(ABSPATH.'wp-settings.php');
?>
Mit diesen Daten erstellt ihr eine neue Datei config.php.
<?php
// ** MySQL settings ** //
define('DB_NAME', 'wpbeta'); // The name of the database
define('DB_USER', 'root'); // Your MySQL username
define('DB_PASSWORD', ''); // ...and password
define('DB_HOST', 'localhost'); // 99% chance you won't need to change this value
// You can have multiple installations in one database if you give each a unique prefix
$table_prefix = 'wp_'; // Only numbers, letters, and underscores please!
?>
Diese Datei wird nun per FTP in das nicht öffentliche Verzeichnis des Servers kopiert, in unserem Beispiel ist das /home/deinname/
Die originale wp-config.php wird nun verändert. Dabei werden die Datenbank-Verbindungsdaten mit Hilfe der include-Anweisung eingebunden.
<?php
include('/home/deinname/config.php');
// Change this to localize WordPress. A corresponding MO file for the
// chosen language must be installed to wp-content/languages.
// For example, install de.mo to wp-content/languages and set WPLANG to 'de'
// to enable German language support.
define ('WPLANG', 'de_DE');
/* That's all, stop editing! Happy blogging. */
define('ABSPATH', dirname(__FILE__).'/');
require_once(ABSPATH.'wp-settings.php');
?>
Damit stehen WordPress die Daten für die Datenbank zur Verfügung und die Datei kann nicht einfach als Text angezeigt werden, denn sie liegt in einem nicht öffentlichen Bereich.
42 Kommentare und 30 Trackbacks zu „Schütze deine wp-config.php“
Kommentar schreiben
Kommentar-Hilfe
händischer Spam:
Beachte die Kommentarregeln, jede Form von versuchtem Spam wird gelöscht. Warum und wieso steht in einem meiner Beiträge.
Bezug auf Textstellen:
Du kannst direkt bezug auf Textstellen im Beitrag nehmen. Dazu muss lediglich der Bereich im Artikel markiert werden; daraufhin erscheint ein Button, der den markierten Text in das Kommentarfeld übernimmt und als Zitat auszeichnet. Die Funktion ist nur bei aktivem JavaScript nutzbar.
xHTML:
Du kannst folgende Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <blockquote cite=""> <code> <pre> <em> <strong> <strike> <ul> <ul> <li>
Achte darauf, wenn du Code im Kommentar hinterlegen willst, dann muss der Code maskiert sein. Dann wird er nicht interpretiert. Der Code muss mit Hilfe von HTML-Entities dargestellt werden, d.h. dass man z.B. < als < und > als > einfügt.
E-Mail-Benachrichtigung bei neuen Kommentaren ?
Wenn der Haken in der Checkbox gesetzt ist, dann wirst du über neue Kommentare vie E-Mail informiert. Der Versand erfolgt nur, wenn du die URL in der Bestätigungs-E-Mail genutzt hast oder schon Abonnent hier im Blog bist.
Kommentar erscheint nicht:
Alle Kommentare werden manuell geprüft, freigegeben und nach Möglichkeit beantwortet. Bitte um etwas Geduld und Nachsicht.
Identifikationsbilder (Avatare):
Auf Gravatar.com kann man sich mit seiner E-Mail-Adresse registrieren und ein Bild hochladen, dann erscheint dieses Gravatar hier und in vielen weiteren Blogs.
Spamschutz:
Das Kommentarformular ist mit einem Spamschutz ausgerüstet. Solltest du diesen Artikel ohne JavaScript besuchen und kommentieren wollen, so muss du die Frage beantworten und das jeweilige Wort in das Textfeld eingeben.
Das Weblog wird angetrieben von
16. November 2007 um 14:49
Habe den Artikel im Original und die verwandten Berichte auch mit grossem Interesse gelesen, zumindest die .htaccess-Variante wird hier demnächst ausprobiert werden, etwas mehr Sicherheit kann nicht schaden.
16. November 2007 um 14:58
Diese Variante habe ich schon länger drin, genau seit dem ich WP 2.4beta gefahren habe. Nun bin ich wieder auf 2.3.1 und noch immer funktioniert es tadellos. Der Zugriff liefert Forbidden.
16. November 2007 um 15:12
16. November 2007 um 21:24
16. November 2007 um 22:08
wo in der .htaccess muss ich das denn einfügen?
17. November 2007 um 00:19
17. November 2007 um 10:11
Vielen Dank für diesen nützlichen Tip! Zwei Fragen eines interessierten Laien - 1. wo kommt der Codeschnipsel hin? Ich habe ihn ganz am Anfang in die htaccess kopiert, gesichert und wieder hochgeladen. Das Blog läuft noch
2. wie kann ich prüfen, ob "forbidden" funktioniert?
17. November 2007 um 11:49
danke, den .htaccess-schnipsel habe ich direkt mal eingebaut!
17. November 2007 um 13:30
Aber ist die wp-config.php denn echt so gefärdet?
Ich frage nur weil ich garnicht wusste das man eine PHP Datei direkt aufrufen und die Daten lesen kann. Eigentlich wird doch alles geparst oder? Den Eintrag mit der htaccess werde ich dann wohl auch benutzen...
Muss ich den Codeschnipsel einfach unter die vorherigen Daten in der htaccess packen? Oder gibts da auch was zu beachten?
17. November 2007 um 13:50
Den Syntax einfach an den bestehenden Inhalt kopieren, eine Leerzeile für die Übersicht ist angenehm
Aufrufen der Datei sollte zu einem forbidden führen, statt einer leeren Seite.
@Jared: Mit Hilfe von Code (PHP o. JS) kann man den Inhalt auch von php-Dateien als txt lesen.
17. November 2007 um 16:13
Thx Frank. Die .htaccess-Methode habe ich gleich umgesetzt. Versuchter Zugriff auf die Datei liefert bei mir ebenfalls ein "Forbidden".
17. November 2007 um 16:15
17. November 2007 um 19:20
18. November 2007 um 01:06
18. November 2007 um 07:41
Hi,
ich habe schon eine htaccess Datei, die folgendermassen beginnt und endet
# BEGIN WordPress
......
......
# END WordPress
wohin schreibe ich den von Di angegebenen code. Wie sieht das Ergebniss dann aus? Kannst Due bitte ein Beipiel geben?
Frage deshalb so genau, weil ich des Programmierens nicht mächtig bin. Liebe Grüße
Jochen
18. November 2007 um 09:01
18. November 2007 um 13:49
@jochen: habe den Beitrag um ein Beispiel erweitert. Hoffe, es fällt damit leichter.
18. November 2007 um 14:40
Super Anleitung, danke!
Ich habe die Variante mit dem Auslagern der Definitionen genommen und alles funktioniert.
18. November 2007 um 19:21
Das ist doch mal ein echt sinnvoller Tip. Dankeschön.
19. November 2007 um 07:35
19. November 2007 um 08:36
19. November 2007 um 10:03
Ohne mich weit aus dem Fenster lehnen zu wollen:
Aber was soll der Aufwand denn?
Bei der normalen wp-config.php kommt doch überhaupt kein Output beim Aufruf zustande, wie soll da was geklaut werden?
Ich mein klar, sicher ist sicher.
Aber doch etwas mit Kanonen auf Spatzen geschossen, oder nicht?
Aber ich lasse mich gerne eines besseren belehren.
19. November 2007 um 10:12
19. November 2007 um 12:24
mal ein einfaches Bsp., auf die schnelle eine php-Datei auslesen:
<?php $file = '.../wp-config.php'; if (!$file) { echo(" Error: unable to load URL file into $file. Process aborted. "); exit(); } $file = file_get_contents($file); highlight_string($file); ?>19. November 2007 um 14:34
Klasse Erklärung. Danke für den Hinweis, Frank.
19. November 2007 um 14:39
@Frank (19. November 2007 um 12:24):
Wenn man mit PHP eine PHP-Datei einliest, dann bekommt man als Ergebnis die HTML-Ausgabe der PHP-Datei, nicht den PHP-Code. Das habe ich gerade ausprobiert.
19. November 2007 um 15:17
@Marco: mit dem Beispiel-Syntax bekomme ich jeden Zeile, 1:1 wie die PHP-Datei. Allerdings habe ich solche Spielereien bisher nur lokal betrieben.
show_source z.B. liefert html, wenn der Server so eingestellt ist. Den Inhalt einer PHP-Datei kann man aber auch als txt auslesen.
19. November 2007 um 16:21
19. November 2007 um 17:43
Das hat meine wp-config so gut geschützt, dass ich interner Servererror 500 bekam. *lach* Erst als die htaccess wieder original war konnte ich wieder zugreifen auf meine installation.
20. November 2007 um 12:50
Hallo Frank,
darf man Fragen wieso du die 3 IPs in deiner .htaccess aussperrst?
20. November 2007 um 13:50
Das ist nur beispielhaft, aber in der Regel ist Contentdiebstahl der Grund.
21. November 2007 um 02:18
Ähm Frank, korrigier mich, wenn ich falsch liege:
Lokal kann ich Dateien immer auslesen, weil da nicht der Apache zwischendurch die htaccess prüft und per Remote (http://, was den Apache ja dazu bringt die htaccess zu prüfen) wird php so der Server richtig eingestellt ist IMMER geparst. Demnach hab ich mit JS (=JavaScript) keinerlei Chancen die Datei auszulesen.
Das Problem, welches auch die "Hacker" beschrieben haben war folgendes:
1. Jemand stolpert eher zufällig über einen Blog.
2. Der Server gibt aus irgend einem Grund (Fehlkonfiguration, Schluckauf, Probleme PHP zu starten, ...) die Datei nicht zum Parsen an PHP weiter
3. Der Besucher bekommt anstelle des Blogs den Quellcode der index.php
4. Der Besucher kennt WordPress und ruft die wp-config.php auf
5. Diese wird auch nicht geparsed sondern so auf die Reise geschickt
6. Zugangsdaten zu MySQL hat jetzt jemand anders
7. Der MySQL User war nicht nur für Lokalhost eingerichtet.
Faktum Akut ist also: Wer Schreibberechtigung auf irgendeiner php-Datei hat, der kann die wp-config.php auch auslesen (und demnach auch die verschobene) wer diesen Zugriff nicht hat - der kanns nur bei Fehlkonfiguration des Servers - und dann geht noch vieeeel mehr
Bei diesem Beispiel halte ich folgende Dinge für äußerst bedenklich:
a) Der Server gibt Quellcodes raus => Das ist eigentlich das letzte was bei nem Produktivsystem passieren darf
b) Der MySQL-User wurde für alle Verbindungen von Außen (Hosts/IPs) eingerichtet - würde ich bei Produktivsystemen wirklich 5x drüber nachdenken, ob das nötig ist. In aller Regel reicht es den User für Localhost einzurichten - dann kann man mit dem User und dem Passwort nur noch was anfangen, wenn man selber ein Hosting Packet auf dem Server hat bzw. die URL zu phpMyAdmin oder eine SQL-Injection Lücke kennt... wobei bei letztem in aller Regel kein User/Passwort benötigt werden...
Eigentlich schützt man sich also davor, dass bei einem Fehlverhalten des Servers relevante Daten weitergereicht werden. Das ist zwar löblich (und ich mache das auch) aber eigentlich sollte man sich lieber davor schützen, dass der Server so nen Mist macht. (Ist halt nur nicht immer möglich, is mir auch klar)
Gruß
Alex
21. November 2007 um 07:49
Hallo Alex,
ich danke für die kurzen und treffenden Auskünfte zum Problem und Apache-Hintergründe.
Grundsätzlich hast du recht, nur dass in den meisten Fällen der Server gehostet wird und man (oft sicher auch gut so) keinen Einfluss darauf hat. Die andere Tür sind die Fehler in der Applikation, die schnell mit einem Plugin ins System geholt sind.
Klar, die Sicherung der wp-config.php ist nur für einen ganz kleinen Teil von möglichen Türen ein Schutz, aber für sehr wenig Aufwand schließt man wieder eine.
* Ich habe nochmal nach dem Artikel, wie man php-Code aus einer Datei ausliest gesucht, aber ohne Erfolg. Hatte den Artikel vor langer Zeit mal gelesen, dachte eigentlich bei gulli, aber ohne Erfolg.
Das Beispiel klappt nur lokal, aber es soll nur mal zeigen, dass wenn der Apache nicht sauber eingerichtet ist, was geht.
LG Frank
23. November 2007 um 10:09
24. November 2007 um 00:20
25. November 2007 um 14:42
27. November 2007 um 12:04
7. Januar 2008 um 17:34
21. Januar 2008 um 11:54
3. Februar 2008 um 16:27
Hallo, ich finde diesen Artikel sehr interessant. Da ich bei einem Blog in rumänischer Sprache mitarbeite (www.cnet.ro), der über WP läuft und in dem macnhmal auch darüber berichtet wird, würde ich ihn gern ins Rumänische übersetzen. Ich weiß nur nicht so recht, ob dies den im Impressum genannten CC 2.5 entspricht. Würde mich auf einer Antwort freuen. Vielen Dank im voraus.
4. Februar 2008 um 08:58
@jtoth: aber sicher, kein Problem, wenn die Quelle angegeben ist.
4. Februar 2008 um 20:58
20. März 2008 um 23:46
27. März 2008 um 11:24
Hallo Frank,
vielen Dank für den Tip. Ich bin in php nicht ganz so tief drin, aber in Deinem Beispiel nicht ein (hoffentlich nimmt er das so) zuviel drin? Also die wp-config.php beginnt ja damit, dann kommt der include für die config.php, aber in der steht doch auch nochmal am Anfang. Beißt sich das irgendwie?
Grüße Martin
27. März 2008 um 11:29
Hatte es befürchtet. also noch ein Versuch:
Ich bin in PHP nicht ganz so tief drin, aber in Deinem Beispiel nicht ein <?php> (hoffentlich nimmt er das so) zuviel drin? Also die wp-config.php beginnt ja damit, dann kommt der include für die config.php, aber in der steht doch auch nochmal <?php> am Anfang. Gibt das dann nicht zwei <?php> hintereinander? Unten wird ja nur eines zugemacht.
28. März 2008 um 11:15
Da passt was nicht, die wp-config.php hat eigentlich keine include.
28. März 2008 um 12:00
Doch, in dem oben im Artikel genannten Beispiel:
include('/home/deinname/config.php');
28. März 2008 um 12:17
Sorry, hatte nicht an die ausgelagerte Variante gedacht.
Ja, muss sein und geschlossen sein.
3. April 2008 um 19:02
6. April 2008 um 15:40
Ich empfehle, den neuen SECRET_KEY auch in den ausgelagerten Teil zu verlegen.
8. April 2008 um 20:39
19. Mai 2008 um 16:20
22. Mai 2008 um 11:23
26. Juni 2008 um 12:17
5. Juli 2008 um 14:14
1. August 2008 um 16:09
16. August 2008 um 10:15
Kannst du bitte das mit dem Verzeichnis verständlicher erklären? Ich kann z.B. mit public_html nichts anfangen.
Danke
16. August 2008 um 11:27
@Elena: public_html ist öffentlich, darauf kann jeder zugreifen. So sind die meisten Webspace konfiguriert. Diese Möglichkeit kommt nur in Betracht, wenn du in deinem Webspace oberhalb des öffentlichen Bereiches zugreifen kannst. Ansonsten die Möglichkeit via .htacces hinterlegen.
16. August 2008 um 19:10
Hallo Frank,
erstmal danke für die vielen interessanten WordPress-Plugins und Erklärungen. Ich hab nach deiner Anleitung die .htaccess modifiziert (ich hab die erweiterte Version kopiert und eingefügt, und lediglich das "bueltge" durch meinen Domainnamen ersetzt und die gesperrten IP´s auskommentiert. Mit der neuen .htaccess kann ich mich jetzt nicht mehr im Backend anmelden... Nach Zurückkopieren der alten .htaccess klappt es dann wieder... Woran könnte das liegen ??
Danke schön und viele Grüße aus Hintertuxingen
Martin
16. August 2008 um 19:20
17. August 2008 um 12:52
@Bürgermeister: Sorry, aber meine Kenntnisse in .htaccess sind auch nicht so dicke.
23. August 2008 um 01:09
25. August 2008 um 03:53
7. Oktober 2008 um 21:13
3. Januar 2010 um 23:12
Hallo liebe WordPressler!
Ich habe ein problem mit der .htacces
Ich bin mir nicht im klaren darüber ob jeztet nur der oben beschriebene Code drinnen stehen muss oder ob auch der AuthUserFile stehen muss. Also bei mir schaut der Kopf ca so aus bevor ich den code vom oben kopiert habe
AuthType Basic
AuthName "Protected Area"
AuthUserFile /..../.htpasswd
Require valid-user
dadurch bekomme ich in wordpress 2.9 mit dem wp-security-scan allerdings eine Fehlermedung mit
Warning: fileperms() [function.fileperms]: stat failed for ../.htaccess in /.../wp-security-scan/functions.php on line 22
Kann mir da jemand weiterhelfen?
LG aus Wien
Andreas
20. Januar 2010 um 11:54
Hallo, mit dem Plugin
http://devel.kostdoktorn.se/limit-login-attempts/kann man seinen Admin Bereich zusätzlich sichern. Nach X versuchen wird eine Wartezeit eingeräumt. Gruss Daniel Kamp26. April 2010 um 10:48
Hallo Frank,
wie immer super hilfreich dein Blog.
Leider kann ich eins meiner Blogs (das ich derzeit neu aufsetze) nicht mehr aufrufen wenn ich den Schutz in die htaccess einbaue.
Folgendes funktioniert:
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
Aber sobald ich die Datei wie folgt ändere, funktioniert es nicht mehr:
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# Schutz der wp-config.php
Order deny,allow
deny from all
Ich bekomme beim Aufruf der Subdomain.domain.de ein 403 Forbidden.
2. Juni 2010 um 18:46
Hallo Tari,
ich hatte dieses Problem auch.
Du mußt noch den Eintrag mit files ergänzen.
Siehe hier:
# schutz wp-config.php
<files wp-config.php>
Order deny,allow
Deny from all
</files>
Damit sollte es funktionieren.
Herzlichen Gruß
Klaus
10. November 2011 um 00:12
Diese Seite scheint schon Feierabend zu haben ;O)
Ich stelle trotzdem mal die Frage.
Macht es sinn die Dateiattribute zu ändern.
Also das Lesen von öffentlich zu verhindernt ?
Oder Besitzer schreibrecht zu verbieten ?
Was hat dies für Auswirkungen ?
Bin gerade am experimentieren.
freundliche Grüße
v Rob.by
16. November 2011 um 23:03
Ehrlich gesagt ich weiss nicht mehr weiter.
seit ich die hier vorgeschlagene .htaccess gebastelt habe geht sozusagen gar nichts mehr.
Die ganze Webseite ist dann nicht mehr erreichbar. Und es ist egal ob nun in meinem URL-Verzeichnis oder in der Verzeichnisebene darunter in der ich die WordPressinstallation untergebrachthabe. Wobei das ja auch falsch ist wie ich mehr und mehr den Eindruck gewinne
Und als totale Anfängerin und Esteinrichterin weiss ich schlicht nicht was ich überhaupt fragen soll und bin kurz davon den Schutz der 'dusseligen' wp-config.php aufzugeben.
17. November 2011 um 14:26
@Maren: nutze nur den Schutz in der .htacces, in dem du die Datei verbietest, mehr nicht. Die htaccess liegt da, wo auch die wp-config.php liegt.
20. November 2011 um 20:28
Vielen Dank für die Ermutigung.
Mit Abstand noch mal draufgucken hab ich den Fehler dann gefunden und auch alles ins richtige Verzeichnis gesteckt. Alles läuft (was bislang nicht gerade viel ist.)
Auch wenn ich als 'Nicht-Hacker' die Wirkung nicht überprüfen kann
Jedenfalls jetzt kann es losgehen.
Viele Grüße
Maren