Nützen Sie die Möglichkeiten der htaccess Datei, Ihren Internetauftritt sicherer zu machen.
Immer häufiger werden Websites attackiert. Am effektivsten schützen Sie sich vor Angriffen mit ein paar Zeilen Code in der htaccess Datei. Das ist nicht wirklich kompliziert und stellt einen wesentlichen Schutz für Ihre Website dar.
Darüber hinaus gibt es weitere Absicherungen die Sie beachten sollten, wenn Sie das Content Management System WordPress verwenden. Diese habe ich in meinem Artikel „WordPress Angriff“ in diesem Blog vorgestellt.
Gerne werden Plugins, wie zum Beispiel >> Limit Login Attempts zur Verteidigung der Websites genutzt. Diese Plugins sind empfehlenswert und erfüllen Ihren Zweck. Dennoch ist bei Ihrer Verwendung zu beachten, dass sie innerhalb von WordPress Verwendung finden. Das bedeutet, dass die Verteidigung Ihrer Website direkt von WordPress durchgeführt wird.
Stellen wir uns das einmal ganz handfest wie eine ‚Festung‘ vor: Dass bedeutet bildlich gesprochen, dass Ihr Internetauftritt von mehr oder minder massiven Steinen geschützt wird, aber ohne ‚feste Außenmauer‘ da steht. Das bietet potentiellen Angreifern deutlich mehr Angriffsmöglichkeiten und deutlich mehr Angriffsfläche.
Zudem ist im Angriffsfall ihre Website selbst mit der Abwehr der Attacke beschäftigt. Dies kann die Nicht-Erreichbarkeit Ihrer Website verursachen, wohlgemerkt NICHT weil Ihre Website gehackt wurde, sondern weil sie gerade damit beschäftigt ist einen Angriff abzuwehren. Das klingt nicht nur unbefriedigend, dass ist es auch …
Besser ist es, wenn Ihr Content Management System (CMS) mögliche Angriffsversuche gleich von aussen abblockt. Angriffe zielen bevorzugt auf den Administrationsbereich eines CMS. Haben Hacker hier Zugriff erlangt, so haben sie Kontrolle über Ihr System und können von dort aus – in Ihrem Namen – ihr Unwesen treiben.
Angreifer sollten diesen Bereich also möglichst niemals zu Gesicht bekommen, noch nicht einmal die schlichte Login Seite Ihres CMS. Das erreichen Sie, indem Sie einen einfachen, aber sehr effektiven weiteren Passwortschutz errichten, der Ihren Administrationsbereich gegen unerwünschte Zugriffe von außen abschirmt.
In diesem Artikel zeige ich Ihnen, wie Sie Ihren WordPress Internetauftritt gegen Angriffe absichern.
Sichern Sie Ihre Website mit der htaccess Datei in 5 Minuten.
Das errichten der oben erwähnten ‚festen Außenmauer‘ ist relativ einfach, Sie benötigen hierzu nicht unbedingt IT-Kenntnisse 😉 Nur ein paar einfache Handgriffe sind notwendig: Ein FTP-Zugang zu Ihrem Webspace, ein FTP-Programm und ein einfacher Text-Editor (Word ist keiner).
Ihre Ausrüstung:
FTP-Zugang:
Sollten Sie diesen gerade nicht parat haben: den Zugang zu Ihrem Fileserver erfahren Sie von Ihrem Provider. Loggen Sie sich in Ihren Kundenaccount ein und halten Sie nach FTP Ausschau. Sie werden dort eine FTP-Adresse, sowie Benutzername und dass zugehörige Passwort erhalten.
FTP-Programm:
FTP-Programme gibt es viele, für alle Plattformen. Sie hier vorzustellen, würde den Rahmen des Artikels sprengen. Eine gute und kostenlose Lösung für alle Plattformen ist Filezilla. >> Laden Sie Filezilla hier herunter, installieren Sie das Programm und richten Sie den Zugang zu Ihrem Webserver ein. Nutzen Sie den Link auf dieser Seite. Sollten Sie einen anderen Link nutzen, dann achten Sie bitte darauf, dass Sie nicht auf irgendwelche Abzocker hereinfallen. Filezilla ist grundsätzlich kostenlos.
Text Editor:
Nutzen Sie zum editieren der htaccess Datei einen einfachen Text-Editor, z.B. den Microsoft Editor (Standard auf Windows-Rechnern) oder TextEdit (Standard auf Apple OS-Rechnern). Nutzen Sie auf keinen Fall Textverarbeitungsprogramme wie Word / Open Office / Page etc. !!!
Alles parat? OK – Los geht´s.
Schritt 1.
Erstellen Sie eine .htpasswd (PUNKThtpasswd)
Erstellen Sie in Ihrem Text-Editor eine neue leere Datei. Rufen Sie den >> Htpasswd Generator auf. In den Eingabefeldern tragen Sie den gewünschten Nutzernamen sowie ein sicheres Passwort ein – aus dieser Kombination aus Benutzernamen und Passwort ergibt sich der Zugang für die .htaccess Abfrage.
Klicken Sie auf den Button zur Erzeugung des htpasswd-Files. Kopieren Sie die vom Htpasswd Generator erzeugte Zeichenfolge – die sieht ungefähr wie folgt aus:
IhrPersoenlicherBenutzername:$apr1$l3IaZD4K$cDVJkiJruLT0alULr3yoW0
in die geöffnete Datei in Ihrem Text-Editor und speichern Sie sie als htpasswd.
Laden Sie diese Datei in ein Verzeichnis innerhalb Ihres WordPress-Verzeichnisses auf Ihren Webserver. Benennen Sie die Datei dort in .htpasswd (PUNKThtpasswd) um. Sie können die Datei in einem von Ihnen erstellten Unterordner ‚verstecken‘.
Beachten Sie bitte:
Der Passwortgenerator verschlüsselt das von Ihnen verwendete Passwort mit dem sogenannten MD5 Algorithmus – aus dem Passwort: Conchita-Wurst-2014 wird verschlüsselt also: $apr1$SgjZFv/0$k43CHibXrsoTwG/72.8wp. Sie müssen sich allerdings nur Conchita-Wurst-2014 als Password merken, nicht die MD5 Verschlüsselung 😉
Schritt 2.
Verknüpfen Sie die .htaccess Datei mit Ihrer
.htpasswd Datei
Navigieren Sie mit Ihrem FTP-Programm in das WordPress-Verzeichniss Ihres Webservers. Suchen Sie dort in der obersten Verzeichnisebene eine Datei mit dem Namen „.htaccess „(PUNKThtaccess) . Erstellen Sie zunächst eine Sicherungskopie der vorhandenen .htaccess Datei. Benennen Sie anschließend die .htaccess in htaccess um. Also OHNE Punkt. Laden Sie anschließend die Datei auf Ihren Rechner herunter und öffnen Sie in Ihrem Text-Editor.
Manchmal existiert noch keine .htaccess Datei in Ihrem WordPress-Verzeichnis. Macht nichts. Erstellen Sie in diesem Fall Ihrem Text-Editor eine weitere neue leere Datei. Fügen Sie in die geöffnete Datei folgenden Code ein und passen Sie den Pfad zu Ihrer .htpasswd Datei nach folgendem Muster an:
https://www.ihre-domain.com/pfad/zu/ihrer/.htpasswd
<Files wp-login.php> AuthName "Admin-Bereich" AuthType Basic AuthUserFile https://www.ihre-domain.com/pfad/zu/ihrer/.htpasswd require valid-user </Files> <FilesMatch "(\.htaccess|\.htpasswd|wp-config\.php|liesmich\.html|readme\.html)"> order deny,allow deny from all </FilesMatch>
Abschließend laden Sie die .htaccess in die oberste Verzeichnisebene Ihres WordPress Verzeichnisses auf Ihren Webserver.
Das war es auch schon.
Hinweis für STRATO-User
Wenn Sie Ihre Website(s) bei dem Provider Strato hosten, löst der oben aufgelistete Code einen Fehler aus.
Nutzen Sie folgenden Code:
In öffnende Tag-Klammern <>files wp-login.php AuthName "WordPress" AuthType Basic AuthUserFile "/home/strato/www/die-ersten-beiden-Buchstaben-ihrer-Domain/https://www.ihre-domain.com/htdocs/pfad/zu/ihrer/.htpasswd " Require user User-Name wie in der htpasswd benannt Require valid-user In schließende Tag-Klammern files In öffnende Tag-Klammern <> filesmatch "(\.htaccess|\.htpasswd|wp-config\.php|liesmich\.html|readme\.html)" order deny,allow deny from all In schließenden Tag-Klammern filesmatch
Weitere Hinweise, wie Sie den Schutz der .htaccess-Datei auf einem Strato-Server einrichten können, finden Sie unten im Abschnitt Kommentare im Beitrag von Marion Lustig vom 09.01.2015.
Fazit:
Natürlich schließt der oben aufgeführte Schutz der htaccess Datei einen Einbruch keinesfalls hundertprozentig aus – eine hundertprozentige Sicherheit gibt es nicht. Zum Beispiel würde ein auf dem heimischen Rechner installierter Trojaner auch diese Anmeldewerte heimlich an einen Späher übertragen.
Die Vielfalt, Hartnäckigkeit und Einfallsfreudigkeit der Hacker scheint unerschöpflich. Doch der Schutz der htaccess Datei ist ein ernstzunehmendes Hindernis auf dem Weg zur feindlichen Übernahme. Es konnte sich in der Vergangenheit bereits vielmals als zuverlässige Abwehr vor ungebetenen Gästen bewähren und vor der Ausnutzung bereits bekannt gewordenen WordPress-Lücken zum Zugriff auf den Administrationsbereich schützen.
Appell zum Schutz der htaccess Datei von Sergej Müller
Lieber eine Passwortabfrage zu viel als zu wenig.
Dringende Aufruf an alle Blogger: Sichert eure Adminbereiche ab! Die Angelegenheit ist schneller und unkomplizierter erledigt als vermutet. Die in den meisten Fällen bereits vorhandene Server-Datei .htaccess (meist von WordPress für die Steuerung der Permalinks angelegt oder für das Caching-Plugin Cachify benötigt) wird um 2 Code-Blöcke mit minimaler Pfadanpassung erweitert.
Für Neugierige:
Was ist eigentlich eine htaccess Datei?
Eine .htaccess-Datei wird bei jedem Zugriff eines Servers auf ein Verzeichnis oder einer Datei im und unterhalb des Verzeichnisses der .htaccess-Datei gelesen und ausgewertet. Wird zum Beispiel von einem Nutzer die Datei „datei.htm“ im Verzeichnis „/Ordner/“ abgefragt, so schaut der Webserver erst in allen höher gelegenen sowie direkt im Verzeichnis „/Ordner/“ nach einer vorhandenen .htaccess-Datei. Dabei werden alle gefundenen .htaccess-Dateien ausgewertet.
Mit Hilfe von .htaccess-Dateien kann man also als Webseitenbetreiber eigene Verzeichnisse komfortabel administrieren, ohne dass an der globalen Webserverkonfiguration des Webservers selbst etwas geändert werden muss. In der Regel besitzt man als einfacher Webseitenbetreiber diese globalen Rechte zur Serverkonfiguration auch nicht.
Wikipedia:
Die .htaccess (engl. hypertext access „Hypertext-Zugriff“) ist eine Konfigurationsdatei auf NCSA-kompatiblen Webservern wie Apache, in der verzeichnisbezogene Regeln aufgestellt werden können. Beispielsweise kann man darüber ein Verzeichnis oder einzelne Dateien durch HTTP-Authentifizierung vor unberechtigten Zugriffen schützen. Auch Fehlerseiten oder Weiterleitungen innerhalb des Servers (siehe Rewrite-Engine) lassen sich darin festlegen, ohne dass der Server neu gestartet werden muss: Änderungen in der .htaccess-Datei treten ohne Weiteres sofort in Kraft, weil die Datei bei jeder Anfrage an den Webserver ausgewertet wird. Bestimmungen in einer .htaccess wirken wie Directory-Abschnitte in zentralen Konfigurationsdateien wie einer httpd.conf. Sie gelten nur für das Verzeichnis in dem die .htaccess gespeichert ist und in allen seinen Unterverzeichnissen, können aber auch in den Unterverzeichnissen überschrieben werden.
Gibt es eine Möglichkeit zu steuern, wie viele Versuche man hat, wenn man htaccess nutzt. Wenn ich das unendliche Male versuchen kann, dann ist es auch kein wirklicher Schutz.
Hallo Jan.
Klare Frage – klare Antwort: Nein.
Aber dies ist kein Grund zu sagen, der Schutz über die htaccess Datei sei „kein wirklicher Schutz“. Es gibt keine wirkungsvollere Sicherungsmöglichkeit für Deinen Admin-Bereich. Die Qualität des Schutzes liegt in der Qualität des von Dir verwendeten Passwortes !!! Je kryptischer es ist, umso schwieriger ist es, es zu knacken. Und umso sicherer ist dann der Schutz über die htaccess Datei.
Aber natürlich gibt es Möglichkeiten weitere Sicherheitsbarrieren aufzubauen.
Denn der Schutz über die htaccess Datei sichert ja – wie in meinem Artikel erklärt – den Adminbereich Deiner WordPressseite ab.
Um eine weitere Barriere zu errichten, verwende am besten >> Limit Login Attempts.
Mithilfe des einfach zu installierenden Plugins limitierst Du die (wiederholten) Anmeldeversuche einer IP auf eine bestimmte Anzahl und verweigerst dann für einen definierten Zeitraum einen weiteren Anmeldeversuch. Dies erschwert so zum Beispiel Brut Force Attacks. Du findest eine Beschreibung des Plugins in meinem Artikel WordPress Angriff.
Die Kombination des Schutzes via htaccess Datei und Limited Login Attemps ist sehr wirkungsvoll. Dennoch – eine 100% Sicherheit gibt es nicht …
Ich hoffe, ich konnte Dich überzeugen den Schutz über die htaccess Datei einzurichten.
Viele Grüße aus Hamburg.
Thorsten
Danke für die Rückmeldung! Mir ging es nur um den Verzeichnisschutz mit Hilfe von htaccess. WordPress liegt nicht hinter/in dem Verzeichnis.
Alles klar, also muss ich ein langes und kryptisches Passwort wählen, damit es nicht geknackt werden kann.
Hallo,
ein echt toller Artikel. Alles sehr einfach erklärt und alles genau beschrieben. Habe mich nun daran gemacht, das ganze auch für meine Seite umzusetzen. Funktioniert auch soweit (also das zusätzliche Login-Formular), aber dann wird mir der reguläre WordPress-Login nicht mehr angezeigt.
Stattdessen kommen die folgende Fehlermeldung:
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator at [no address given] to inform them of the time this error occurred, and the actions you performed just before this error.
More information about this error may be available in the server error log.
Apache Server at wiese.de Port 80
Was ist denn da falsch? Wie kann ich dieses Problem lösen? Habe leider keinen Zugriff auf die Server-error-log
Hallo Franz,
danke, dass Dir der Artikel gefällt.
Die Fehlermeldung kann mehrere Ursachen haben. Überprüfe zunächst, ob Du einen Fehler in dem in die .htaccess eingefügten Code hast.
Zb. fehlende, oder falsche Zeichen? Leerzeichen? Oder ähnliches.
Ein andere Fehlerquelle könnte im Code selbst liegen. Bei welchem Provider bist Du?
Strato benötigt einen etwas abweichenden Code, in den Kommentaren unten folgen weitere Hinweise zu unterschiedlichen Providern.
Grüße aus Hamburg,
Thorsten
Hallo Thorsten, vielen Dank für deine Antwort!
Mein Anbieter ist alfahosting.de
die Fehlermeldung tritt dann auf, wenn ich folgenden Code in die htaccess einfüge:
AuthName "Admin-Bereich"
AuthType Basic
AuthUserFile http://meineseite.de/wp-sicher/.htpasswd
require valid-user
Also am zweiten Abschnitt, der noch einzufügen wäre, liegt es nicht.
Hallo Franz,
ich freue mich, dass Dein Problem gelöst werden konnte und Deine Website nun mit einem .htaccess-Schutz ausgestattet ist.
Vielen Dank, dass Du den benötigten Code für alphahosting.de hier geteilt hast. Das wird anderen Usern, die ihre Website bei diesem Provider hosten, helfen.
Grüße, Thorsten
Hallo Thorsten,mein Anbieter hat mir geholfen, das Problem zu lösen. Auch bei diesem Anbieter braucht man einen etwas anderen Code. Dir noch einen schönen Tag
Hallo Thorsten,
danke für die tolle und klare Beschreibung!
Die htaccess lösung funktioniert perfekt.
Was ich gerade festgestellt habe, und was sicherlich nicht mit dem htaccess-datei zu tun hat, ist dass mein admin namen „meinNameblabla“ erscheint in der Google-Ergebniss.
http://www.meindomain.de/en/author/meinNameblabla/
Es ist sehr seltsam auch weil ich „0“ Beiträge geschrieben habe
Hat das vielleicht mit polylang zu tun?
Was kann ich da tun?
Hallo Sergio,
vielen Dank, dass Du den .htaccess-Schutz für Deine WordPress-Website eingerichtet hast.
Deine Frage liefert mir leider zuwenig konkrete Hinweise, als das ich sie beantworten könnte. Zudem kenne ich mich mit polylang nicht aus.
Hast Du Dir schon meinen „Beitrag So sichern Sie den WordPress Author-link“ angeschaut?
Viele Grüße,
Thorsten
Hallo und guten Tag,
besten Dank für die super Anleitung. Hat bei mir bestens funktioniert 🙂
Allerdings habe ich jetzt folgendes Problem:
Ich habe ein paar WordPress-Seiten, die ich in WordPress mit einem Passwortschutz versehen habe, damit diese nur bestimmten Besuchern mit Kenntnis des Passworts zugänglich sind.
Wenn jetzt auf diesen Seiten das korrekte Passwort eingetragen wird, dann kommt die Abfrage vom Benutzernamen und Passwort aus der .htpasswd!
Lassen sich dazu in der .htaccess „Ausnahmen anlegen“, so dass diese Seiten mit dem „Seitenpasswort“ aufgerufen werden könne, ohne dass die Zugangsdaten für den Adminbereich aus der .htpasswd bekannt sind?
Beste Grüße
Gerald
Hallo Gerald,
wunderbar, dass der Schutz über die .htaccess Datei funktioniert. Und – leider – nein, es lassen sich keine „Ausnahmen anlegen“. Benutzer-Accounts für registrierte User laufen ebenfalls über den Adminbereich von WordPress.
Das ist ein allgemeines Problem und ich mag das auch noch nicht so voll und ganz akzeptieren. Auf meiner Artikelliste steht das Thema weit oben. Ich habe aber noch keine Zeit gefunden zu de Thema umfassend zu recherchieren. Aber Dein Kommentar hat mich motiviert, dass Thema anzugehen. Sobald ich ein wenig Luft habe, fasse ich da nach.
Stay tuned.
Grüße aus Kalkriese,
Thorsten
Guten Tag und vielen Dank für ihren Blogbeitrag.
Zurzeit ist meine Login-URL auf eine ganz andere geändert, so dass Angriffe auf die Standard-URL ins leere laufen bzw. die Nutzer eine Fehlermeldung erhalten.
Doch ich ziehe in Erwägung, dies rückgängig zu machen und stattdessen genau diese Sicherung bei mir zu integrieren.
Nun habe ich folgende Fragen:
– Wie schon erwähnt ist die Login-URL nicht mehr der Standard. Macht es hier einen Unterschied, wenn der Login-URL eine andere ist?
– Muss eine ganz bestimmte Reihenfolge der einzelnen Codeblöcken wichtig, oder ist die Reihenfolge tatsächlich egal?
Gruß
Ahoi Manarine.
Das ist eine sehr interessante Fragestellung.
Grundsätzlich lässt sich jedes Verzeichnis mit einer .htaccess schützen. Insofern lässt sich Ihre Vorgehensweise (einer verschobenen ../login.php) mit einem Schutz der htaccess Datei sehr gut kombinieren. Sie müssen Ihre Vorgehensweise also nicht rückgängig machen. Sie müssten nur sicher stellen, dass die von Ihnen verschobene Login-Seite in einem eigenem Verzeichnis liegt.
Konkret bedeutet dies: In diesem Verzeichnis legen Sie eine htaccess Datei an und versehen sie mit dem im Artikel beschriebenen Schutz. Auf den entsprechend angepassten Pfad zur .htpasswd müssen Sie natürlich ebenfalls achten.
Den zweiten Teil Ihrer Frage – bezüglich der Reihenfolge der Codeblöcke – habe ich leider nicht ganz verstanden. Was ist hier gemeint? Bitte beachten Sie, dass es bei bestimmten Providern (zB. Strato) bestimmte Vorgaben zum Schutz der htaccess Datei gibt, also eine exakte Syntax, wie der Code strukturiert sein muss.
Viele Grüße,
Thorsten
Ich bin leider ein absoluter Laie, was Programmieren betrifft. Eure gut Anleitung habe ich verstanden. Nur eines ist mir nicht ganz klar. Was trage ich in der Zeile:
AuthUserFile https://www.ihre-domain.com/pfad/zu/ihrer/.htpasswd
bei „ihrer“ ein? Das generierte Passwort? Meinen Benutzernamen? Oder bleibt das so stehen?
Könnt ihr mal ein Beispiel geben?
Gruß Ben
Hallo Ben,
hmm – ich überlege, wie ich ein besseres Beispiel als das gegebene: https://www.ihre-domain.com/pfad/zu/ihrer/.htpasswd für Dich finden kann. Vielleicht, indem ich den Pfad anders darstelle:
Wenn Du Dich mit Deinem FTP-Program auf Deinem Server eingeloggt hast, befindest Du Dich in der Regel in dem Root-Verzeichnis. In diesem Root-Verzeichnis liegen viele weitere Unterverzeichnisse (= Ordner).
Du legst in eines dieser Unterverzeichnisse die Datei .htpasswd.
Damit die .htaccess dieses Verzeichnis dann auch finden kann, musst Du den Pfad zu der Datei .htpasswd. in der .htaccess hinterlegen.
Mein Beispiel https://www.ihre-domain.com/pfad/zu/ihrer/.htpasswd kannst Du also folgendermaßen lesen: Rootverzeichnis/erster_Unterordner/zweiter_Unterordner/weitere_Unterordner/…/.htpasswd
Du gibst also einen Pfad mit Ordnernamen ein, der zu der gewünschten Datei führt – keinesfalls aber einen Benutzernamen oder gar ein Passwort!
Ich hoffe, so wurde es für Dich klarer.
Viele Grüße,
Thorsten
Ich überlege schon länger diese Art der Sicherung anzuwenden, habe mich bisher jedoch nicht rangewagt. Werde das aber nun mal versuchen.
Danke schöner Beitrag
Hallo DC Webdesign,
ein guter Entschluss! Die Absicherung des Admin-Bereiches durch die htaccess ist der stärkste Schutz gegen Website-Hacks. Nicht nur Deine Kunden werden davon profitieren, auch das Netz wird damit insgesamt ein Stückchen sicherer.
Grüße aus dem sonnigen Hamburg,
Thorsten
Hallo – wie im vorigen Beitrag beschrieben habe ich bei 1&1 das Verzeichnis /wp-admin mit einer .htacess-Datei versucht zu schützen. Wenn ich mich anmelde werde ich auch nach dem zusätzlichen User und Kennwort gefragt – aber das Plugin „Limit Login Attempts“ noch immer Anmeldeversuche über ausländische IP’s versucht …
Da auch bei ener domain bei Domainfactory nach Einrichtung der .htaccess-Datei über das Plugin festgestellt wird das unberechtigte Anmeldeversuche und IP-Sperrungen stattfinden – war die Einrichtung des .htaccess „zu spät“ ? oder ist es doch im wp-admin an der falschen STelle ? Bei 1&1 wird aber auch dieses Verzeichnis angegeben – und mit dem oben beschriebenen „…“ geht es nicht – ich bin neu auf dem Gebiet und etwas ratlos ….
Grüße
Hallo Sven,
nach der Einrichtung des .htaccess-Schutzes sollten keinerlei Anmeldeversuche via Limit Login Attempts mehr auftreten (können). Ich habe diese Kombination bei diversen Projekten im Einsatz und das Phänomen, welches Du beschreibst ist nie aufgetreten. Daher gehe ich davon aus, dass bei der Konfiguration etwa schief gegangen ist. Zu ergründen woran es liegt, wird jetzt etwas zu komplex für eine Ferndiagnose ohne Einblick in Deine Konfiguration.
Hast Du Kontakt mit dem Support Deines Providers aufgenommen und direkt nach einer Problemlösung nachgefragt? Das wäre der Weg den ich an Deiner Stelle jetzt einschlagen würde.
Eine weitere Möglichkeit Dich abzusichern ist die 2-Fach Authentifizierung mit dem Google Authenticator.
Diese zusätzliche Authentifizierung in zwei Schritten, über die Du Dich mit Hilfe der Google Authenticator-App und des >> Google Authenticator WordPress-Plugins in Dein Backend einloggen kannst, bietet Dir zusätzliche Sicherheit: Ist dass Plugin installiert, gibst Du bei einem Login in das Backend nicht nur den WordPress-Benutzernamen und das Passwort ein, sondern zusätzlichen einen vom Google Authenticator-App neu generierten Google Authenticator Code.
Du benötigst für die Nutzung des Google Authenticator ein mobiles Device (Smartphone oder Tablet) und die entsprechende App.
Dieses musst Du immer zur Hand haben, wenn du auf Dein WordPress-Backend zugreifen möchtes. Dies bietet einen äußerst sicheren zusätzlichen Schutz vor Hacker-Angriffen. In der Handhabung ist allerdings eher etwas umständlich.
Die Einrichtung des Google Authenticator gestaltet sich mit Hilfe des WordPress-Plugins recht einfach:
Nach der Installation des WordPress-Plugins und dem Download und der Google Authenticator-App auf Dein mobile Device kannst du ganz einfach den Barcode in den WordPress Plugin-Einstellungen nutzen. (Dafür benötigst Du eine weitere App, einen Barcode-Scanner).
Nach dem Scan des Barcodes wird das WordPress-Plugin mit deiner App verknüpft.
Die Google Authenticator-App generiert Dir in Intervallen immer wieder neue Login-Codes für deine WordPress-Seite. Du trägst den generierten Code beim Login in das zusätzliche Feld in Deinem WordPress-Loginscreen.
Die App kannst Du hier herunterladen:
>> Google Authenticator Android-App auf GooglePlay
>> Google Authenticator als iOS App
Ich werde dieses Thema demnächst in einem komplett neuen Artikel in Angriff nehmen.
Viele Grüße aus Hamburg,
Thorsten
Hallo Thorsten,
Danke für Deine Antwort. Ich hatte sowieso schon an den Support geschrieben – hier die Antwort:
Wir haben dies soeben einmal genauer angesehen. Um noch bessere Sicherheit gewährleisten zu können, würden wir Ihnen empfehlen in der .htaccess anstatt von „valid-user“ die User aufzulisten, die sich auch tatsächlich anmelden dürfen. Es ist möglich, dass diese versuchen auf das Backend zuzugreifen, allerdings ist dies nicht möglich, sofern der Schutz aktiv ist.
Leider hat dies auch nicht geholfen. Auch der Tausch der Sicherheitsschlüssel in der wp-config.php hat nicht geholfen.
Nach „ausführlichen Gesprächen“ mit Tante Google und endlich den richtigen Suchbegriffen bin ich über diesen Beitrag https://forum.wpde.org/allgemeines/151943-fehlgeschlagene-anmeldeversuche-trotz-htaccess-datei.html auf diese Seite gekommen: https://www.heise.de/ct/hotline/Angriff-auf-XML-RPC-zwingt-WordPress-in-die-Knie-2585367.html
Nachdem ich heute morgen die xmlrpc.php umbenannt habe herrscht tatsächlich Ruhe …..
Im übrigen sieht meine .htaccess jetzt so aus, und funktioniert bei 1&1 und Domainfoctory im Root-Verzeichnis:
# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# Schutz der wp-config.php
Order deny,allow
deny from all
AuthName "Admin-Bereich"
AuthType Basic
AuthUserFile /EUER-PFAD/.htpasswd
require valid-user
order deny,allow
deny from all
# END WordPress
Dann hatte ich gestern noch einen Videoworkshop gebucht und angesehen (daraus auch diese .htaccess :;) ) und werde mir das darin empholene Sicherheitsplugin https://wordpress.org/plugins/all-in-one-wp-security-and-firewall/screenshots/ mit den empholenen Einstellungen installieren – auf meiner privaten „Übungsseite“ bei 1&1 habe ich es schon im Einsatz – und darüber die XML-RPC-Schnittstelle ausgeschaltet, seit dem ist dort auch „Ruhe“ 🙂
Grüße
Sven
Guten Morgen,
es ist noch immer „ruhig“ 🙂
Leider wurde der Coder meiner .htacces irgendwie gefilter und nicht ganz dargestellt – ich versuche es nochmal:
# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# Schutz der wp-config.php
<Files wp-config.php>
Order deny,allow
deny from all
</Files>
# Ende Schutz
<Files wp-login.php>
AuthName "Admin-Bereich"
AuthType Basic
AuthUserFile /EUER-PFAD/.htpasswd
require valid-user
</Files>
<FilesMatch "(\.htaccess|\.htpasswd|wp-config\.php|liesmich\.html|readme\.html)">
order deny,allow
deny from all
</FilesMatch>
# END WordPress
Grüße Sven
Hallo Sven,
ich habe die Codezeilen angepasst (WP erlaubt aus guten Gründen keinerlei direkte Codeangaben in Kommentaren).
Grüße, Thorsten
Leider werden wohl die „spitzen Klammern“ herausgefiltert, daher fehlen diese ….. evtl. könnte Thorsten dies noch korrigieren oder ich könnte irgendwie ein Bild hochladen ….
Grüße Sven
Hallo Sven,
vielen Dank, dass Du hier Deine Lösung für alle zur Verfügung stellst.
In den nächsten Tagen, die sicherlich etwas ruhiger werden, werde ich die Code-Darstellung hier verbessern.
Ich wünsche Dir schöne Feiertage,
Thorsten
Hallo Thorsten,
ich habe das gleiche Problem wie Stef am 12.Mai 2016 beschrieben hat. Liegt es etwa an 1&1 als Provider ? Weil über das Control-Center kann ja ein verzeichnisschutz eingerichet werden – aber dann würde doch die bestehende „Word-Press-httacces“ überbügelt werden ?
Danke für Deine Hilfe und Grüße Sven
Hallo Thorsten,
bei einer Vereinsseite – Provider Domainfactory – kommt ebenfalls nach Eingabe der Userdaten ein „Fehler 500 – Scriptfehler“ …..
Grüße
Sven
.htaccess Schutz (Provider Domainfactory)
# .htaccess-Datei fuer ein Verzeichnis
AuthType Basic
AuthName „TopSecret-Bereich“
AuthUserFile https://www.ihre-domain.com/pfad/zu/ihrer/.htpasswd
AuthPGAuthoritative Off
require user
Detailierte Hinweise findest Du hier:
https://www.df.eu/de/support/df-faq/webhosting/weitere-technische-faq/htaccess/
LMGTFY 😉
Hallo Sven,
ich selbst hoste leider nicht bei 1und1 und habe daher keine direkte Erfahrungen mit diesem Provider.
Zu 1und1 hat Mario Hühne weiter unten am 7. Juli 2015 at 14:01 folgendes gepostet:
#BEGIN Auth
AuthName "Admin-Bereich"
AuthType Basic
AuthUserFile https://www.ihre-domain.com/pfad/zu/ihrer/.htpasswd
require valid-user
order deny,allow
deny from all
# END Auth
Er schreibt, mit diesem Eintrag war er erfolgreich …
Probiere es bitte einmal so.
Zu Deiner Frage:
Weil über das Control-Center kann ja ein verzeichnisschutz eingerichet werden – aber dann würde doch die bestehende „Word-Press-httacces“ überbügelt werden ?
Auch das kann ich leider nicht ohne einen Einblick in die Prozesse von 1und1 evaluieren.
Du kannst es aber sehr leicht herausfinden, indem Du zunächst auf Deinem FTP-Server die .htaccess-Datei duplizierst (Sicherheitskopie) und anschliessend über das Controll-Center den entsprechenden Verzeichnisschutz etablierst. Ein anschliessender Blick in die .htaccess auf dem FTP-Server verschafft Dir dann Klarheit, ob das Control-Center in eine bestehende .htaccess-Datei eingreift, oder diese einfach überschreibt.
Grüße aus Hamburg,
Thorsten
*Nachtrag:
Ich habe das eben mal gegoogelt und im Hilfecenter von 1und1 folgendes gefunden – hast Du da schon mal reingeschaut?
1und1 Hilfecenter: WordPress Login mit .htaccess-Datei absichern
Hallo Thorsten,
Danke für Deine Hilfe. Ob Du es glaubst oder nicht – ich habe auch Tante Google gefragt (sonst wäre ich ja nicht auf Deiner Seite gelandet 🙂 ) und habe unter anderam auch die von Dir gepostete Hilfe-Seite von 1&1 gefunden – neben dieser: https://hilfe-center.1und1.de/hosting/1und1-hosting-c10085285/webspace-und-zugaenge-c10085091/verzeichnisschutz-c10085367/verzeichnisschutz-mittels-htaccess-und-ftp-einrichten-a10795539.html
Leider musste ich schon öfter feststellen, dass die 1&1 Hilfeseiten entweder veraltet oder fehlerhaft sind – oder ich zu blöd bin, das so umzusetzen. Jedenfalls kommt auch nach dieser Anleitung bei mir eine Fehlerseite.
Dank Deines Hinweises auf den Post von Mario Hüne vom 7. Juli 2015 habe ich jetzt im /wp-admin Verzeichnis eine .htaccess-Datei mit folgendem Inhalt abgelegt:
#BEGIN Auth
AuthName "Admin-Bereich"
AuthType Basic
AuthUserFile /DOCUMENTROOT/pfad/zu/ihrer/.htpasswd
require valid-user
# END Auth
Dies scheint zu funktionieren – wenn noch
order deny,allow
deny from all
enthalten ist hab ich ja überhaupt keine Zugriffsberechtigung mehr ……
Bei der Vereinsseite bei Domain-Factory funktioniert es jetzt auch – offensichtlich hatte ich da „dicke Finger“ und irgendwas falsch geschrieben …..
Auch war ich da erst irritiert, da ich die das Verzeichnis /wp-admin aufgerufen sonder nach der Domain gleich /wp-login.php aufgerufen habe und das Anmeldeformular gesehen habe – da dachte ich, dass der Schutz nicht hilfe. Heute habe ich die Anmeldedaten angegeben und abgeschickt, dann kam erst die htaccess-Abfrage …..
Ich bin da noch „unerfahren“ – auch was WordPress angeht. Wollte schon dabei bleiben, und es halt auch richtig absichern. Kannst Du für die Sicherheit Plugins empfehlen oder weitere „manuelle Tipps“ geben ?
Danke nochmal und Grüße
Sven
Ach ja – noch ein Hinweis bzgl. der .htaccess-Einrichtung über das 1&1-Control-Center:
Ich wollte diese erstellen und dann den Inhalt anpassen – Erstellen war auch kein Problem, nur dann ist der Besitzer (oder Eigentümer) „root“ und somit ist mit anpassen nix …….
Nochmal Grüße
Sven
Ich finde prinzipiell die Absicherung des login-forms eine der besten Sicherheits-Strategien. Allerdings: Was ist mit den Loginoptionen, die WP mitbringt für die Registrierung (und entsprechend dann auch Login) von Abonnenten, Kunden (Woocommerce) etc.
Ich betreue jetzt beispielsweise schon zwei Websites, die notwendigerweise über solche Logins verfügen, sei es wegen Woocommerce, sei es wegen s2members. Natürlich kann ich hier die wp-login absichern. Aber dann ist es ja ein leichtes, das s2member-Login anzugreifen oder das woocommerce-Kundenlogin .
Wie bewertet Ihr das? Die Absicherung der wp-login stellte wohl eine erste Blockade dar, die vor allem die automatischen Standard-Knackversuche erst einmal abhält. Mehr aber sicherlich nicht – da frage ich mich schon: Lohnt der Aufwand?
Bin gespannt auf Eure Meinungen!
Hallo nici-
Das Absichern eines WordPress-Logins und das Anbieten einer Anmeldeoption für Kunden stellen sich gegenüberstehende Anforderungen dar: Mit der Absicherung über die htaccess-Datei wird das WordPress Backend geschützt. WooCommerce & Co. sollen aber Kunden die Möglichkeit bieten, sich im System anzumelden um bestimmte Services im Frontend nutzen zu können.
Ein WooCommerce Nutzer ist nichts anderes, als ein WordPress Nutzer. Der htaccess-Schutz sichert – oder behindert – demzufolge ebenso den Kunden-Login, auch registrierte Nutzer müssen an der Sicherheitsbarriere vorbei und benötigen hierfür die htaccess-Zugangsdaten. Das ergibt natürlich keinen Sinn.
(Frage: Ich habe mich kurz umgeschaut und keine befriedigende Antwort gefunden, ob man htaccess-Schutz und Kunden-Login irgendwie kombinieren kann. Hat hierzu jemand eventuell Tipps?)
Wirksamer Schutz lässt sich in diesem Falle zunächst mit den (von mir stets vorausgesetzten) Standardhilfsmitteln, wie zum Beispiel sichere Usernamen/Passwortkombinationen, Eingabe der entsprechenden Sicherheitsschlüssel in der wp-config.php, etc. erreichen, ergänzt mit einer dezidierten Rollen- und Zugriffsverwaltung.
Die Bordmittel von WordPress sind leider nicht wirklich ausreichend, hier sollte unbedingt nachgerüstet werden, zum Beispiel mit >> User Role Editor oder das mächtige >> Members.
Um dennoch zu verhindern, dass ein Wordpres-Admin Ordner manipuliert werden kann, kann man über einen FTP-Account die Dateizugriffsrechte herunter setzen. WordPress benötigt dort nur Leserechte, damit alles reibungslos funktioniert. Ausnahmen stellen natürlich Updates dar, dann müssen die Rechte vorübergehend hoch gesetzt werden, um diese durchführen zu können. Etwas umständlich, aber zweckdienlich.
Viele Grüße aus Hamburg,
Thorsten
Vielen dank für den tollen Artikel und die ausführliche Information. Die Informationen sind ziemlich hilfreich.
Gruß Anna
Hallo Anna,
vielen Dank für das Lob, ich freue mich, wenn die Informationen Dir weiterhelfen konnten.
Thorsten
Hat jemand Erfahrung mit dem .htaccess-Schutz (spez. wp-login.php) und dem Mitglieder-Plugin DigiMember? Wenn der Schutz aktiv ist, kann man sich aus DigiMember nicht mehr ausloggen. Dann erscheint das Fenster mit der Abfrage von Kennung und Passwort. Komischerweise aber nur/erst beim Ausloggen. Beim Einloggen über DigiMember aber nicht.
Hallo Götz,
ich kenne das Plugin DigiMember leider nicht.
Hast Du Dich schon beim Anbieter des Plugins erkundigt?
Vielleicht kennt hier jemand das Plugin DigiMember und kann Götz weiter helfen?
Grüße aus Hamburg,
Thorsten
Danke für Deine Rückmeldung, Thorsten.
DigiMember hab‘ ich schon angeschrieben, leider ohne Reaktion (2 Anläufe)
An error occurred. Username or password contains illegal characters
Bekomme ich jedesmal beim Htpasswd Generator … habe nur Groß-, Kleinbuchstaben und Zahlen verwendet…
Hallo,
bei mir erscheint das externe Anmeldefenster. Allerdings kann ich mich mit dem von mir gewählten Benutzernamen und Passwort nicht anmelden. Es erscheint nach einem Anmeldeversuch erneut das externe Anmeldefenster. Ich habe alle möglichen Pfadvarianten zur .htpasswd ausprobiert. Ich verwende als Hosting-Anbieter uberspace. Gibt es hier evtl. etwas Besonderes zu beachten?
Grüße
David
Hallo David,
leider habe ich keinerlei Erfahrungen mit diesem Provider, so dass ich diesbezüglich nicht weiterhelfen kann. Ich gehe davon aus, dass Du die entsprechende Syntax in Deiner .htaccess Datei überprüft und auch das hinterlegte Passwort in der .htpassword überprüft und gegebenenfalls ausgetauscht hast.
Hast Du schon direkt beim Support von uberspace nachgefragt, ob es irgendwelche Besonderheiten gibt, die beim Schutz der .htaccess-Datei beachtet werden müssen?
Vielleicht weiss hier jemand anderes Rat? Dann wäre es großartig, wenn der- oder diejenige David weiterhelfen könnte.
Viele Grüße aus Hamburg,
Thorsten
Wenn die richtige Symtax nicht anders herauszubekommen ist, hilft vielleicht dieser Weg: Lege ein neues leeres geschütztes Verzeichnis über die Website des Providers an. Die meisten bieten diese Möglichkeit an. Schau per FTP die hierfür erzeugte .htaccess an und ämdere den Pfad sinnentsrechend für den WP-Schutz.
Das Problem, das David hat, ist der verlinkte Generator für die htpasswd-Datei. Bei mir kam das gleiche. DIe Fehlermeldung ist offensichtlich, weil der Generator nicht mehr richtig funktioniert. Ich hatte sogar ein Passwort nur aus Buchstaben probiert und trotzdem kam das. Um Ersatz zu finden, kann man einfach im Netz nach „htpasswd generator“ suchen. Da gibt es jede Menge, die funktionieren.
Hallo,
ich habe mir auf meiner Domain WordPress installiert und wollte jetzt den Admin Bereich von WordPress noch zusätzlich in Verbindung mit einer .htpasswd Datei absichern. Wenn ich die .htaccess mit folgendem Inhalt lasse (von WordPress selbst generiert) klappt alles sehr gut :
# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond % !-f
RewriteCond % !-d
RewriteRule . /index.php [L]
# END WordPress
---------------------------------------------------------------------------------------
Füge ich jedoch folgende Daten hinzu, bekomme ich einen 505er Serverfehler :
# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQ
UEST_FILENAME} !-f
RewriteCond % !-d
RewriteRule . /index.php [L]
AuthType Basic
AuthName "Protected Area"
AuthUserFile /var/www/web11/html/wp-content/.htpasswd
Require valid-user
# END WordPress
Ich habe die .htpasswd Datei unter : /var/www/web11/html/wp-content/.htpasswd .htaccess ist in /var/www/web11/html/ abgelegt. Hatte auch schon an „chmod“ (welchen Wert ?) als Fehler gedacht bin aber noch nicht so gut mit WordPress weil ich vorher immer Joomla genutzt hatte.
Grüße
Stefan
Hallo Stefan,
auf die Schnelle fällt mir auf, dass der zweite Teil des im Artikel aufgeführten Codes (Files match …) zu fehlen scheint.
LG, Thorsten
Hallo,
also wenn ich eine .htacess verändere bekomme ich mit :
# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
AuthName "Admin-Bereich"
AuthType Basic
AuthUserFile /var/www/web11/html/wp-content/.htpasswd
require valid-user
order deny,allow
deny from all
# END WordPress
Auch wenn ich unter : AuthUserFile https://www.ihre-domain.com/pfad/zu/ihrer/.htpasswd eingebe anstatt des absoluten Pfades auf dem Server bekomme ich :
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, [no address given] and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.
Apache Server at http://www.prozess-beobachter.de Port 80 .
Musste somit wieder folgenden Code entfernen und alles funktioniert wieder normal:
AuthName "Admin-Bereich"
AuthType Basic
AuthUserFile /var/www/web11/html/wp-content/.htpasswd
require valid-user
order deny,allow
deny from all
Grüße
Stefan
Hallo Stefan,
habe ich das richtig verstanden, mit der letzten Variante hat es funktioniert?
Nein, habe nochmal gelesen, nur der Internal Servererror taucht dann nicht mehr auf.
Bei welchem Provider liegt Deine Seite? Hast Du die Kommentare zu diesem Artikel gelesen?
Es gibt bei einigen Providern unterschiedliche Codezeilen, die verwendet werde müssen.
Viele Grüße,
Thorsten
Hallo Steff, hatte ich zuerst auch weil der Pfad zur .htaccess Datei falsch war!
Bei mir hat es geholfen, den direkt als Ordner auf dem Server anzugeben, z.B. mit der „wo-bin-ich“ Datei hier aus Schritt 2, ich hoffe das hilft noch anderen!
https://www.computerhilfen.de/info/wordpress-absichern-htaccess-schutz-mit-zweitem-passwort.html
Hallo an alle!
@ Rainer Engel
Hallo Rainer wir hatten uns vor ein paar Wochen über Ninja Firewall für WordPress unterhalten.
Auf der Seite https://fastwp.de/3904/ steht über das Plugin in den ersten beiden Blocktexten, dass Ninja Firewall Bots UND CRAWLER aussperrt!
Wird dann WordPress überhaupt noch in dem Umfang im Index aufgenommen wie sonst? Wenn der Google Bot ausgesperrt wird, wird ihm das nicht gefallen!!!
Kannst du mir mal bitte irgendwie Einstellungen von Ninja Firewall zukommen lassen?
Bolle
Hallo,
genau der zitierte Beitrag hat mich auf Ninia Firewall aufmerksam gemacht. In den nächsten Tagen gebe ich meine Website öffemtlich frei und werde verfolgen, ob die Suchmaschinen sie finden – oder ob Ninja blockiert. Ich kann mir nicht vorstellen, dass Ninja bekannte Suchmaschinen aussperrt – wohl aber, dass es auch Crawler gibt, die keine erwünschten Absichten haben. Aber ich werde genau hinschauen und hier mal kurz berichten.
Ich danke schon mal…
Ziel ist es doch, DAS ein WP-Blog im Netz gefunden wird, sonst würde es doch für die Masse keinen Sinn machen. Ich bin gespannt. Viel mehr auf deine Einstellungen des NInja! Mein Englisch ist zwar im Durchschnitt aber man weis ja nie welche Einstellungen auch Sinn machen. Also bis die Tage
Danke
Bolle
@Rainer Engel
Hallo Rainer,
hast du schon Ergebnisse seitens des Crawler Tests mit Ninja Firewall?
Ich habe die Ninja Firewall jetzt mal installiert und bekomme einfach keine Login Protection hin.
wenn ich Yes if it under attak anklicke, springt der Harken wieder auf No (default) mit der Meldung „HTTP authentication user name is not valid.“
Zu deinen Einstellungen brauche ich mal Hilfe!
Manche schreiben auch dass sie eine .ini Datei configuriert haben!?
Wo soll die den sein 😉
Bolle
[…] und hat wohl auch so seine Fehler, allerdings ist es eine Möglichkeit. Und wer sich mit dem Passwortschutz der .htaccess-Datei nicht auskennt, hat ohnehin nicht viele andere […]
Strato überlistet
Hier hatte ich ja schon berichtet, dass es mir gelungen ist, meine Website bei Strato nach dieser Anleitung abzusichern. Strato läuft aber nicht ohne Probleme, vor allem in der Performance. Hier einige Tipps, die nicht nur bei Strato helfen.
1. Absoluten Pfad feststellen.
In https://www.htaccesstools.com/articles/full-path-to-file-using-php/ fand ich die Anleitung, wie man den absoluten Pfad zur hinterlegten htpasswd Datei findet.
Man platziert im gleichen Verzeichnis eine fullpath.php mit diesem Inhalt:
-------------
<?php
$dir = dirname(__FILE__);
echo "Full path to this dir: " . $dir . "";
echo "Full path to a .htpasswd file in this dir: " . $dir . "/.htpasswd" . "";
?>
-------------
und ruft sie mit dem Broser auf. Funktioniert auch bei Strato. Vor allem geht es schneller: Strato muss den in Anfühungszeichen eingegebnen Pfad nicht mehr auf diesen Wert umrechnen.
2. Weiter kann man das Passwort auch oberhalb des WP-Verzeichnis platzieren. Den absoluten Pfad findet man so: Das Verzeichnis über den Verzeichnisschutz im Kundenbereich schützen. Dann die so erzeugte .htaccess herunterladen und den Pfad herauslesen und in die .htaccess für WP einfügen. Geht auch bei Strato.
3. Wenn man die ganze WP-Installation mit Passwort absichert, etwa zu Testzwecken, dann können zeitgesteuerte Aktionen möglicherweise nicht ausgeführt oder getestet werden. Es gibt oft nicht einmal eine Fehlermeldung und man steht vor einem Rätsel, es geschieht einfach nicht, was soll. Lösung: Das Passwort blockiert die wp-cron.php.
So ging es mir mit dem wertvollen Plugin „Post Expirator“, der Posts zeitabhängig löscht. Es funktionierte einfach nicht, niemand hatte eine Erklärung. Bis ein anders Plugin mich auf die Fährte brachte. Mit der admin-Absicherung klappt es aber.
4. Ein Viertes für Leute, die gern gut absichern: Email-Adressen in Webseiten kann man mit WP Antispambot sehr effizient verschlüsseln. Nachzulesen zum Beispiel hier: https://blog.kulturbanause.de/2015/02/e-mail-verschluesselung-in-wordpress-antispambot/. Dafür gibt es Plugins, aber es genügt auch ein Eintrag in der functions.php und die Verwendung des Codes im Seitenaufbau.
Danke noch einmal für die Tipps auf dieser Seite!
Hallo Rainer Engel,
ich bin begeistert über Deine ausführliche Erläuterung – das wird Vielen helfen, die mit Strato zu kämpfen haben. Ich hoffe, Du verzeihst mir, dass ich (minimal) in die Formatierung Deines Textes eingegriffen habe, um die Lesbarkeit etwas zu verbessern.
Vielen Dank,
Thorsten
Danke für diese Anleitung. Bei all-inkl.com funktioniert AuthUserFile https://www.ihre-domain.com/pfad/zu/ihrer/.htpasswd aber so nicht.
Stattdessen muss es heißen:
AuthUserFile /www/htdocs/loginname_im_KAS/pfad/zu/ihrer/.htpasswd
Dann funktioniert es einwandfrei.
Hallo Rainer-Maria,
vielen Dank für Deine Information, die ich sehr gerne hier mit aufnehme.
Ich denke, ich muss demnächst im Artikel alle in den Kommentaren aufgeführten Abweichungen der diversen Hoster an einer zentralen Stelle sammeln, damit sie übersichtlich zur Verfügung stehen.
Viele Grüße,
Thorsten
[…] Admin abgesichert (Dank an Art-Supplies für den […]
Hallo, danke für die schöne Anleitung.
Ich habe sie befolgt und komme auch zu der gewünschten Eingabemaske.
Nach (korrekter) Eingabe von Benutzername und Passwort komme ich jedoch immer auf einen „Internal Server Error“.
Ich weiß nicht so recht weiter.
Hoster ist 1blu
Vielen Dank
Hallo Hannes,
das kann unterschiedlichste Ursachen haben und lässt sich leider nicht ohne weiteres eingrenzen.
1. Stelle zunächst den ursprünglichen Zustand der .htaccess wieder her und überprüfe, ob sowohl der Login als auch die Ausgabe Deiner Website wieder funktionieren.
2. Überprüfe, ob Du den Code korrekt in die .htaccess eingetragen hast (achte auf Leerzeichen, Tippfehler, etc.)
3. Schaue ins Forum von 1blu (zum Beispiel hier https://faq.1blu.de/content/490/579/de/wie-kann-ich-dateien-und-verzeichnisse-mit-einem-passwort-schuetzen.html), ob es Besonderheiten gibt, die man dort beim .htaccess-Schutz anwenden muss, möglicherweise ist es dort ähnlich wie bei Strato (siehe weiter unten in den Kommentaren).
Viel Erfolg,
Thorsten
Vielen Dank für die schnelle Antwort.
Die ursprüngliche htaccess Datei hatte ich natürlich vorsichtshalber gesichert, so war nach einem kurzen Rückspielen jener der Zugang zur Webseite jederzeit möglich 🙂
Ich werde mich mal schlau machen und dann hier bereichten.
Eine schöne Woche
Nabend @ all!
@Torsten: Deinen Artikel den du vorschlägst habe ich bereits gelesen, da er aus dem Content hier verlinkt war 😉
Ich hab mir deine Seite mal in die Favoriten getan…
@ Rainer: Danke für die Mühe, dass mit dem Ninja werde ich morgen auf einer WP Demo Install mal testen.
Nur zur Info!
Ich bin soweit ich weis noch nicht erfolgreich gehackt. Finde es nur sehr Komisch das ich 3 Schutzmechanismen hintereinander gebaut habe und keine 24h später erste falsche Anmeldeversuche gemeldet bekomme.
Der komplette Login Screen ist an einem anderen Link als gewohnt. Der Ankreifer kann den Pfad gar nicht wissen um eine Eingabe vorzunehmen! Ich versteh das nicht, dass das so einfach geht! Jetzt muss er quasi nur noch das Passwort knacken.
Muss noch eben einen Artikel schreiben. Morgen werde ich mir das genau anschauen.
Mir ist da „All In One WP Security“ Plugin aufgefallen! Nicht schlecht, dass kann alles in einem! Logins begrenzen und Anmeldemaske verschleiern, scannen usw.
Was haltet ihr davon???? Das Plugin hat über 600.000 + Downloads! Taugt das was???
Hier mal der Link auf Youtube: https://www.youtube.com/watch?v=CJvCTlVtazA
Bolle
Hatte „All In One WP Security“ getestet und bei Google developers die Performance überprüft.
https://developers.google.com/speed/pagespeed/insights/
Je nach Einstellung ein Performance-Verlust von mindestens 10 bis zu 20 Prozentpunkten festgestellt. Ninja Firewall kommt mit 3 Prozentpunkten aus.
Der zweite Grund, „all in one“ nicht so gut zu finden, ist das Update-Problem.
Schon das Update von WP 4.4.1 auf 4.4.2 hat mir Plugin-Probleme bereitet. Je mehr ein Plugin auf einmal macht, um so mehr Risiken habe ich beim WP-Update. Ninja Firewall zeichnet sich dadurch aus, dass es ein Stand-alone ist, nur die Bedien-Oberfläche ist ein Plugin. Das sehe ich als sehr interessantes Konzept und bin auf die Langzeiterfahrungen gespannt.
Hallo Rainer!
OK, den Pagespeed wollte ich schon erhalten und ist auch ein gutes Argument!
Dann deinstalliere ich mal „Lockdown WP Admin“ scheint eh nicht zu funktionieren.
Soll ich „Limit Login Attempts“ zusätzlich drauf lassen?
Was brauche ich also alles? Ich hätte gerne einen sicheren Zugriff und eine Überwachung auf infektion bzw. Firewall!
Eingerichtet hätte ich dann bisher: .htaccess-Zugriff (double login) + Limit Login Attempts + Ninja kommt hinzu!
Bin ich dann gut aufgestellt?
Bezüglich der Einrichtung der „WP-Ninja Firewall“ brauche ich allerdings Hilfe! Im Netz habe ich nur Reviews aus den USA gefunden. Auch bei YOU TUBE war nix auf Deutsch! (Hier könnte noch jemand nachlegen 😉 )
Ich habe jetzt auch nicht vor, Torstens Website mit Frage Antwort Threads zuzumüllen! Eine brauchbare Anleitung zum Ninja wenns geht auf Deutsch währe toll! LINK
Vor allem wie da am Anfang der Server einzurichten ist.
Bolle
Hallo Bolle, Hallo Rainer,
Ich bin äusserst angetan davon, dass hier zwischen Euch ein so reger Austausch entstanden ist.
Insofern (@Bolle), mache Dir keine Sorgen, dass Du hier meine Blog „zumüllst“.
Das Gegenteil ist der Fall und genau dies mit einer der Gründe, warum ich diesen Blog aufgesetzt habe: Erfahrungsaustausch und Wissenstransfer.
Also, lasst uns daran teilhaben, was ihr rausfindet …
Leider bin ich zur Zeit beruflich zu stark eingebunden, um mich hier voll in das Thema mit einbringen zu können. Ich möchte aber zumindest auf den Blog von Andreas Hecht (Dr. Web) hinweisen, der einen Artikel bezüglich der .htaccess/Wordpress-Thematik verfasst hat, der einige weitere nützliche Tipps enthält:
https://www.drweb.de/magazin/die-8-nuetzlichsten-htaccess-tricks-fuer-wordpress-50807/
Thorsten
Noch mal zu Ninja Firewall (NF): Beim Einrichten musste ich die php.ini von Hand nach Anweisung von NF ergänzen, automatisch ging es nicht. Ansonsten nutze ich die Grundeinstellungen. Interessant ist, dass NF sich in der .htaccess einnistet. Ich hatte nämlich die .htaccess durch eine ältere Version ersetzt – und schon war ich selbst von NF ausgesperrt. Zurücksetzen der php.ini setzte NF dann außer Betrieb. Also auch ein professioneller Firewall nutzt die .htaccess!
Danke, Thorsten, für diese Seite. Ohne sie hätte ich mich nur gewundert – jetzt verstehe ich Systeme!
Hallo Thorsten,
ich habe deinen Beitrag gelesen, sehr interessant.
Das double Login mit der htaccess Datei habe ich bereits gehabt!
Weiterhin benutze ich das „Lockdown WP Admin“ Plugin um die loginseite zu verschleiern und auf einen anderen Pfad zu lenken als über den Aufruf „www.deine Seite/wp-login.php….
Doch Pustekuchen, bereits nach 24 h meldet das Plugin „Limit Login Attempts“ das ich nur auf eine Fehleingabe des Passwortes eingestellt habe, bereits mehrere unerlaubte fehlerhafte Passwort Eingaben!!!!
Ich werd noch wahnsinnig 😉 Wie kann das sein, das man ein Double Login knackt und auf eine 404 Seite weitergeleitet wird, die Anmeldemaske nichtmal zu Gesicht bekommt und dann eine Eingabe machen kann???
Alle Themes die ich nicht brauche sind gelöscht!
Alle Plugins die installiert sind werden geupdatet! Sind aber nicht viele…
Ich weis echt nicht mehr weiter.
Die Angriffe kommen aus Laos und China!
Bolle
Auch ich habe meine Seite mit htaccess geschützt. Weiter läuft Limit „Login attempts“ mit 3 Versuchen (1 Versuch scheint mir zu scharf, ich vertippe mich ja selbst mal). Schließlich noch Ninja Firewall, weil der wenig Ressourchen braucht. Alles problemlos. Als erste Hilfe würde ich Limit login attempts und Lockdown WP Admin aus dem Plugin-Ordner löschen, um wieder an die Admin-Seite zu kommen. Dann bei wp.org nachlesen, ob es neue Problemmeldungen zu Plugins gibt. Da lese ich immer die 1-Stern-Bewertungen. Und siehe da: Lockdown WP Admin macht aktuell Probleme und führt zu 1-Stern-Bewertungen. Das kann auch an einer neuen WP-Version liegen. Also weg damit. Schließlich verstehen wir Neulinge nicht, was das Plugin wirklich macht.
Hallo Bolle,
oops – das klingt übel …
Und lässt sich in der Ferndiagnose kaum beantworten. Hast Du mal (anonym im Browser unterwegs) versucht die Default-Loginseite aufzurufen (würde möglicherweise auf ein hartnäckiges Cachingproblem hinweisen, wenn erfolgreich).
Da Du ja von Angriffsversuchen schreibst, gehe ich erstmal davon aus, dass der Hack noch nicht erfolgreich war (???)
Vielleicht findest Du in meinem Artikel: https://blog.art-supplies.de/wordpress-backdoor-finden/ Hinweise, wie Du weiterkommst, falls der Angriff doch erfolgreich war und alle Abwehrversuche erfolglos sind, weil der Hacker durch die Hintertür kommt.
Viele Grüße aus Hamburg,
Thorsten
Hallo Rainer,
vielen Dank für Deine Tipps an Bolle.
@Bolle – wenn Du die ausprobierst, dann gib uns hier doch bitte einmal eine Rückmeldung, ob Rainers Lösung bei Dir erfolgreich verlaufen ist.
Danke,
Thorsten
[…] Eine sehr ausführliche und nützliche Anleitung, wie der Admin-Bereich der eigenen WordPress-Installation mit der htaccess-Datei zusätzlich geschützt werden kann, findet sich z. B. hier. […]
Hallo zusammen,
ich habe WP im einem Unterverzeichnis installiert. Also Strato-Kunde möchte ich jetzt die Internetseite über die Hauptdomain (wunschdomain.de) abrufbar machen (und nicht über wunschdomain.de/unterverzeichnis
Wie mach ich das am besten? Soll ich eine Domainweiterleitung bei Strato machen?
https://codex.wordpress.org/Giving_WordPress_Its_Own_Directory Hier steht auch einiges dazu, jedoch weiß ich nicht, wie ich verfahren soll.
Viele Grüße
Hallo ichbleibe@anonym.de
Eine sehr schnelle Antwort auf „Deine schnelle Frage“ findest Du zum Beispiel auf wordpress.org : Wie man WordPress trotz Installation in einem Unterverzeichnis über das Hauptverzeichnis aufrufen kann.
Viel Erfolg,
Thorsten
Dazu benötigst Du weder die Domainweiterleitung noch eine Änderung in der .htaccess. Die index.php ist die geignete Datei dafür. Ich mache das immer nach folgender Anleitung. Das funktioniert providerunabhängig (auch bei Strato):
BEISPIEL UNTERORDNER /wordpress
1. Daten sichern
2. WordPress Backend/Einstellungen/Allgemein: Website-Adresse (URL) offiziellen Link eintragen
3. Über FTP-Programm index.php (und – falls vorhanden – .htaccess) aus dem neuen WordPress-Verzeichnis (z.B. /wordpress) in das Hauptverzeichnis kopieren
4. In der index.php (im Hauptverzeichnis) folgende Zeile ändern:
ALT: require(‚./wp-blog-header.php‘);
NEU: require(‚./wordpress/wp-blog-header.php‘);
5. evt. vorhandene alte index.html löschen
6. WordPress/Einstellungen/Permalinks: Permalink-Struktur aktualisieren
6. Bilder/interne Links kontrollieren
8. Suchmaschinen zulassen (Google Analytics-Code einfügen)
Hallo Marion,
vielen Dank für die sehr gute Anleitung.
Ich nehme an, das wird ichbleibe@anonym.de weiterhelfen.
Liebe Grüße,
Thorsten
# Only allow direct access to specific Web-available files.
# Apache 2.2
Order Deny,Allow
Deny from all
# Apache 2.4
Require all denied
# Akismet CSS and JS
Allow from all
Require all granted
# Akismet images
Allow from all
Require all granted
php_value post_max_size 16M
php_value upload_max_filesize 16M
php_value max_file_uploads 32M
php_value max_input_vars 5000
AuthName "Admin-Bereich"
AuthType Basic
AuthUserFile /home/strato/www/WU/www.wunschdomaine.de/htdocs/WordPress_02/mein/verzeichnis/.htpasswd
require valid-user
order deny,allow
deny from all
Leider funktioniert es nicht. Ich habe den Code am Ende der vorliegenden htaccess eingefügt. Mache ich hier was falsch? (Hoster Strato)
Dank für die Hilfe 🙂
Hallo Meinhard.
bei Strato ist ja gerne alles anders. Da ich selbst meine Seiten nicht bei diesem Hoster betreibe, kann ich Dir leider nicht direkt weiter helfen.
Weiter unten in den Kommentaren findest den Code für Strato. Marion Lustig hat ihn zur Verfügung gestellt und M.Gyger hat dazu noch eine Ergänzung gepostet.
Du solltest diesen Code verwenden..
Viel Erfolg,
Thorsten
Hallo Thorsten,
danke für deine schnelle Antwort. Kleine Ergänzung noch: in meinem gekauften Template lag bereits eine htaccess-Datei, die ich um entsprechenden Code, den auch Strato empfiehlt (https://www.strato.de/faq/article/3.html), ergänzt habe. Leider erfolglos
Problem ist gelöst:
Der Code
php_value post_max_size 16M
php_value upload_max_filesize 16M
php_value max_file_uploads 32M
php_value max_input_vars 5000
muss _ohne_ den Zusatz php_value in einer php.ini Datei gespeichert werden. Dann klappt es auch mit htaccess
Grüße
Hallo Meinhard,
super, dass Du das Problem lösen konntest und das Ergebnis hier teilst.
Vielen Dank.
Thorsten
Auch als Newcomer und Strato-Kunde habe ich diese Anleitung erfolgreich umsetzen können – Danke!
Hallo R.Engel.
Super – dass freut mich.
Grüße aus Hamburg,
Thorsten
Welchen Code hast du denn in die .htaccess Datei eingegeben, bzw. welches Verzeichnis?
Danke
[…] versuchen. Du verdoppelst deine Sicherheit. Die Anpassung ist nicht schwer und in Minuten erledigt. HIER findest Du eine leicht verständliche […]
Hat geklappt.
Hatte ein Problem mit der Verbindung zur htpasswd.
Mit dem http Pfad hat es nicht funktioniert.
Mit dem unc pfad hat es geklappt.
Den korrekten unc pfad kann man per php ermitteln.
Hallo Max,
wunderbar, dass es geklappt hat.
Kannst Du bitte genauer erläutern, wie man den UNC-Pfad mit PHP ermittelt.
Ich kenne UNC (Universal Naming Convention) nur im Zusammenhang mit Netzlaufwerken in der Windows-Welt.
Das wäre spannend,
LG, Thorsten
Vielen Dank für diesen Artikel – gut und verständlich erklärt. LG Marina aus Berlin
Hola Marina,
Danke sehr.
LG aus Barcelona,
Thorsten
Dankeschön für den aufschlussreichen Artikel. Ich kämpfe zur Zeit mit starken Performanceeinbrüchen meines Blogs und bin über diverse Artikel zur .htaccess Datei gestolpert. Mir ist jedoch im cPanel File Manager ein Missgeschick passiert. Das Resultat: die .htaccess Datei wurde überschrieben und ich besitze kein Backup. Habe versucht über die manuelle WordPress-Installation wieder an die Datei zu kommen, jedoch war sie nicht im Ordner enthalten.
Durch das Löschen der Datei, konnte ich zwar wieder den Zugriff auf die Website erhalten, jedoch mache ich mir sorgen, dass sie nicht geschützt ist. Ist die Datei Webhosterabhängig? Gibt es eine Möglichkeit die ursprüngliche wiederherzustellen, bzw. eine neue anzulegen?
Viele Grüße
Alex S.
Hallo Alexander,
Dein Missgeschick mit der .htaccess.Datei kannst Du ohne großen Aufwand beheben:
Du kannst sie ganz einfach mit einem beliebigen Editor (Word ist keiner!) neu erstellen.
Einfach ein neues Dokument anlegen und dort folgenden Inhalt der Standard-WP-htaccess einfügen:
# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress
Danach speicherst Du die Datei unter folgenden Namen: .htaccess und lädst diese anschliessend in Dein WordPress-Stammverzeichnis.
Wohl gemerkt – diese Version gilt für ein aktuelle Basic-WordPress-Instanz. Multisite etc. erwarten eine andere htaccess.Datei.
Mehr über WordPress htaccess.Dateien erfährst Du hier.
Und: JA!
Der Schutz einer WP-Instanz via .htaccess ist Provider-abhängig, in den Kommentaren zu diesem Artikel wirst Du den einen oder anderen diesbezüglichen Kommentar entdecken.
Die frisch angelegte .htaccess behebt allerdings nicht Dein Performance-Problem. Dieses Problem ist komplex und kann verschiedene Ursachen haben, die ganz unterschiedliche Lösungsansätze erfordern.
Beschäftige Dich diesbezüglich mit den verschiedenen Caching-PlugIns, die angeboten werden. Da es sich in diesem Artikel um die .htaccess.Datei dreht, kann ich Dir folgenden Code für die Steuerung des Verhaltens des Browser-Cachings anbieten (passe die Zeitangaben nach Deinen Bedürfnissen an):
# EXPIRES CACHING #
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"
ExpiresDefault "access 2 days"
# END EXPIRES CACHING #
Vielleicht hilft dies schon weiter?
Viel Erfolg.
Thorsten
Vielen Dank für die schnelle Antwort Thorsten. Sie hat mir sehr geholfen!
Viele Grüße
Alex S.
Hallo Alexander,
Wunderbar, dass hört sich erfolgreich an.
Ich freue mich sehr, dass ich Dir helfe konnte.
Grüße aus dem sonnigen Hamburg,
Thorsten
Danke für diesen Artikel.
Nun konnte ich den Adminbereich sicherer machen.
Wir nutzen 1und1 und haben folgendes eingetragen:
#BEGIN Auth
AuthName "Admin-Bereich"
AuthType Basic
AuthUserFile /kunden/homepages/12/d123456789/htdocs/gutscheine/wordpress2/.htpasswd
require valid-user
order deny,allow
deny from all
# END Auth
Hallo Mario.
Super, dass Dein Admin-Bereich nun auch stark abgesichert ist und danke für Deine Infos bzgl. der Einstellungen in der htaccess-Datei bei 1 und 1.
Das wird vielen weiterhelfen.
Viele Grüße aus Hamburg,
Thorsten
Hallo Thorsten,
wenn ich meine Webseite (wp-admin) mit .htaccess absichere, habe ich eine Einschränkung in meiner WordPress Installation (sowohl bei Strato als auch bei 1und1).
Einzelne Seiten im WordPress können über „Sichtbarkeit“ mit einem Passwort abgesichert werden. Wenn ich dieses mache, kommt beim Seitenaufruf auch die .htaccess-Abfrage. Der Gast auf der Webseite soll aber nur das Passwort der einzelnen Seite eingeben müssen.
Hast Du eine Lösung?
Vielen Dank.
Dieter
Hallo Dieter.
Nein – leider weiss ich adhoc hierfür keine Lösung.
Da ich das Problem noch nicht hatte, habe ich mich damit noch nicht auseinander gesetzt. Vielleicht hat sonst jemand eine Lösung/Antwort für Dieter?
Am besten schaust Du Dich einmal im Forum der deutschen WordPress Community um und stellst dort eine Anfrage:
https://forum.wpde.org
Sowohl Strato als auch 1und1 sind – was Einstellungen angeht – sehr speziell. (siehe auch die Kommentare von Marion Lustig und M.Gyger.) Möglicherweise hilft also eine Anfrage direkt beim Provider weiter, aber ich denke, eine Anfrage im WordPress-Forum wird die Lösung am ehesten hervorbringen.
Viel Erfolg! Wenn Du es geschafft hast, wäre es toll, wenn Du die Lösung hier im Blog mit uns teilst.
Grüße aus Hamburg,
Thorsten
Bei Strato ist – mal wieder – alles etwas anders:
Dort muss man folgenden Code in die .htacces eingeben:
Achtung bei der Pfadangabe des AuthUserFile gibt es bei Strato drei Besonderheiten:
1.) Alles muß in Anführungszeichen gesetzt werden.
2.) Nach www/ müssen Sie die ersten beiden Buchstaben Ihrer Domain einsetzen (in diesen Beispiel also ih)
3.) Zwischen Domain und Unterordner muß noch ein htdocs/ eingefügt werden.
Liebe Marion,
leider hat der Eintrag so bei mir nicht funktioniert. Ich es führte zu einem „Internal Server Error“.
Ich habe dann bei Strato in den FAQs nachgesehen und dort finde ich die Zeile:
AuthUserFile /home/strato/www/wu/www.wunschname.de/htdocs/.htpasswd
damit war dann der Internal Server Error weg.
auch
AuthUserFile „/home/strato/www/wu/www.wunschname.de/htdocs/.htpasswd“
gibt das gleiche Ergebnis, die Anführungstriche scheinen also egal zu sein.
Beste Grüße
M. Gyger
P.S. Nach dem ich die leere Zeile unter der mit dem Passwort in der .htpasswd Datei entfernt habe, klappt auch die zusätzliche Passwortschleife 🙂
Hallo M. Gyger,
vielen Dank für deine Ergänzung.
Marion Lustig
Erstmal vielen Dank für die Anleitung. Noch ein kurzer Nachtrag bezüglich des Pfades zur .htpasswd:
Dieser war bei mir leider nicht wie im Artikel beschrieben. Um den richtigen Pfad herauszufinden kann man sich, sofern aktiviert, per SSH auf den Server verbinden und mit der Abfrage pwd den genauer Ordnerpfad abrufen.
Grüße
Uwe
Hallo Uwe,
danke für Dein Ergänzung.
Grüße aus Hamburg,
Thorsten
Vielen Dank für den hilfreichen Artikel, nach weihnachtlichem Malware-Hack kann ich jedem nur empfehlen, alles mindestens doppelt abzusichern – das braucht immer noch weniger Zeit als die Fehlersuche, Seiten-Sperrung und eine Neu-Installation nach einem Hack.
Zum Passwort-Generator: deutsche Umlaute scheint er offensichtlich nicht zu vertragen.
Zur .htaccess noch eine Frage: der 2te Teil muss mit rein? (Files match….)
VG Alex
Hallo Alex.
OOOps – das klingt nach Weihnachtsstress … ich hoffe, Du bist aus aus dem Gröbsten raus.
Umlaute
Si – die sind doppeltplusungut und sollten generell vermieden werden. Auch der Passwort-Generator verträgt sie nicht – vielen Dank für Deinen Hinweis.
.htaccess
Yepp. Auch der zweite Teil des Codes (Files match …) gehört unbedingt hinein.
(Nachtrag: Um das zu vereinfachen habe ich das zu einem Kasten zusammengefügt.)
Ich wünsche Dir ein frohes neues Jahr,
Thorsten
Vielen Dank für diesen Artikel – gut und verständlich erklärt. Habe noch eine Frage dazu: Wenn ich mehrere Admins im Blog habe, muss ich dann für jeden ein Passwort generieren und eintragen, oder reicht das nur für einen Benutzer? Freue mich über eine Antwort 😉
Hallo Irene,
ich freue mich, dass mein Artikel Dir weiterhelfen konnte.
Ich bin mir nicht sicher, ob ich Deine Frage richtig verstanden habe.
Deswegen gibt es hier zwei Antworten:
Antwort 1
Wenn Deine Frage darauf zielt, ob Du für jeden Admin einen eigenen .htaccess Account anlegen musst, dann lautet meine Antwort schlicht:
NEIN – Musst Du nicht.
Antwort 2
Du hast mehrere Benutzer-Accounts eingerichtet, die den Benutzernamen „Admin“ haben und diese Benutzer haben auch Admin-Rechte?
Dann lautet meine Antwort:
JA – Musst Du!
Wie man Benutzernamen ändert, findest Du hier:
https://blog.art-supplies.de/wordpress-admin-account-andern/
Du solltest generell für jede Art WP-User den Benutzernamen „Admin“ NICHT verwenden. Denn der Benutzername ist ja die eine Hälfte des geheimen Benutzer-Accounts. Jeder Benutzer sollte natürlich auch über sein eigenes Passwort verfügen.
Zudem solltest Du nicht jedem Benutzer Admin-Rechte erteilen, denn ein Admin darf ja immer alles. Das ist aber zum Beispiel für einen Redakteur, der Beiträge verfassen darf, aber (zum Beispiel) keine Plugins installieren soll, auch gar nicht nötig.
Dafür gibt es in WordPress die unterschiedlichen Benutzerarten.
Hier noch mal schnell eine Liste der möglichen Benutzerarten im Backend:
Administrator = Administrator
Editor = Redakteur
Author = Autor
Contributor = Mitarbeiter
Subscriber = Abonnent bzw. Registrierter Benutzer
Welcher Benutzer welche Rechte besitzt, findest Du hier auf >> wordpress.org (engl.)
Ich hoffe, ich habe Deine Frage richtig verstanden und die richtige Antwort war dabei …
Viele Grüße, Thorsten
Prima – dann ist Antwort 1 für mich die richtige 😉
Dass man den Namen Admin nicht wählen sollte, ist mir schon lange klar, ich meinte eher Benutzer mit Adminrechten 🙂
In meinem Fall ist es so, dass ich grundsätzlich immer zwei Benutzer anlege, die Adminrechte haben. Daher rührte meine Frage.
Danke für Deine Antwort und lieben Gruß
Irene
Hallo!
Gerade für mich als WordPress Anfänger war der Artikel wirklich eine tolle Hilfe – vor allem wirklich verständlich geschrieben und für jedermann einfach umzusetzen!
Danke Thorsten!
Hallo Andreas,
vielen Dank für Dein Lob.
Und: SUPER – dass Du Deine WordPress-Seite durch die .htaccess-Datei geschützt hast. Je mehr einzelne WordPress-Instanzen abgesichert werden, je schwerer wird es für Hacker neue Server zu kapern um von diesen aus weitere Seiten anzugreifen.
Das ist sehr wichtig, denn man unternimmt nicht nur etwas für sich selbst, man schützt indirekt auch Andere. Und das mit einem wirklich geringen und gut zu bewältigenden Aufwand.
Viele Grüße aus Hamburg,
Thorsten