Um das zu beantworten, müsste man erstmal klären wie man überhaupt eingesetzte Plugins und Themes erkennen kann. Dafür gibt es viele Wege:
Der Seitenquelltext ist dafür absolut gut geeignet. Dort stehen lange nicht alle drin – aber diejenigen die irgendetwas im Frontend machen.
Dann kann man auch noch die Plugin-Verzeichnisse einfach versuchen aufzurufen. Wenn der Server das DirectorListing aktiviert hat (was hoffentlich niemand mehr macht), kann man sich hier fatalerweise durch alle Verzeichnisse und Dateien schlängeln – vorausgesetzt das Plugin hat keine index.php hinterlegt, dann würde die statt des Verzeichnisse angezeigt werden. Auf dem Weg könnte man rausbekommen, dass ein Plugin installiert ist, aber nicht ob es auch aktiviert ist.
Jedes Plugin aus dem WordPress Repository hat eine readme.txt. Wenn man die im Pluginverzeichnis aufrufen kann, weiß man, dass das Plugin da ist – man weiß nur nicht, ob es auch aktiv ist. Hier bei wp.org gibt es z.B. das Gutenberg-Plugin dank dem man diesen Editor hier hat: https://de.wordpress.org/support/wp-content/plugins/gutenberg/readme.txt – und ja, wer danach sucht muss ein Verzeichnis möglichst vieler Plugins zur Hand haben was er dann einzeln prüfen kann. Da das WordPress Repository öffentlich ist, ist es sehr einfach an so eine Liste zu kommen. Das Scan-Vorgang könnte nur länger dauern oder man beschränkt sich auf „die großen“.
Auch gibt es Plugins die sich auf anderen Wegen in die Ausgabe der Website einmischen. Sei es ein angepasste Login-Formular, ein zusätzlicher HTTP-Header oder eine robots.txt.
Du merkst: es gibt viele Wege um Plugins zu erkennen. Und daher ist es auch schwierig sie zu verstecken. Ich könnte mir daher ein paar mögliche Maßnahmen vorstellen:
- DirectoryListing deaktivieren (unbedingt!)
- Den direkten Aufruf der
readme.txt verhindern, z.B. durch eine .htaccess oder nginx.conf-Regel.
- Den Scan von bestimmten Verzeichnissen z.B. durch Prüfung von zugreifenden IPs und/oder User Agents verhindern. Das wäre eher eine Aufgabe einer Firewall mit Content-Filter, die dem WordPress vorgelagert sein müsste.
Ich bin unsicher, ob es für einzelnes davon Plugins oder fertige Lösungen gibt. Solche Absicherungen sind i.d.R. sehr individuelle Einstellungen die nur wenige Projekte überhaupt vornehmen. Daher frage ich mich auch was der Hintergrund deiner Frage dazu ist? Geht es dir um eine Absicherung deines Projektes? Du musst hier schon zwischen Aufwand und Nutzen abwägen.
Es gäbe noch eine Alternative, die für erheblich mehr Sicherheit sorgt: statische Seiten. Mit Plugins wie Statify kann man sich sein WordPress als statische Dateien erzeugen lassen. Diese legt man dann unter der Domain ab. Das eigentliche WordPress ist nicht öffentlich erreichbar. Dadurch verschwindet jeglicher mögliche Angriffsvektor. Die statischen Seiten haben ja nicht mal eine Datenbank im Hintergrund. Klappt natürlich nur, wenn der Aufbau vom Projekt so etwas zulässt.
Danke @threadi für deine ausführliche und kompetente Rückmeldung. Ich mir einmal genauere Gedanken dazu machen. Ebenfalls danke für deine vorgeschlagenen drei Massnahmen.
Zu deinen zwei ersten vorgeschlagenen Punkte:
- DirectoryListing deaktivieren (unbedingt!)
- Den direkten Aufruf der
readme.txt verhindern, z.B. durch eine .htaccess oder nginx.conf-Regel.
Kann ich dies bedenkenlos in die Wege leiten oder kann ich dies die Funktion der Website oder eines Plugins einschränken?
Hi threadi,
du schreibst u.a.:
Ich könnte mir daher ein paar mögliche Maßnahmen vorstellen:
- DirectoryListing deaktivieren (unbedingt!)
- Den direkten Aufruf der
readme.txt verhindern, z.B. durch eine .htaccess oder nginx.conf-Regel.
- Den Scan von bestimmten Verzeichnissen z.B. durch Prüfung von zugreifenden IPs und/oder User Agents verhindern. Das wäre eher eine Aufgabe einer Firewall mit Content-Filter, die dem WordPress vorgelagert sein müsste.
Das wäre doch mal ein interessanter Ansatz, so was wie ein Tutorial zur Absicherung von WordPress zu schreiben. Ich denke, dass es im Forum mehr Leute interessieren würde. Ich wüßte z.B. nicht, wie man das genannte vornimmt, aber ich bin da sicher kein Maßstab 😉
Wie oben schon angedeutet sind das Dinge die nicht jeder machen muss. Der Aufwand und Nutzen ist je nach Projekt nicht gegeben. Es gibt Sicherheitsplugins die sich um Teile davon für dich kümmern. Je nach Anforderungen des Projektes könnten aber eben auch zusätzliche Absicherungen sinnvoll sein.
Kann ich dies bedenkenlos in die Wege leiten oder kann ich dies die Funktion der Website oder eines Plugins einschränken?
Wenn man die oben formulierten Dinge nicht richtig angeht, kann es die Funktion der Website beeinflussen. Für einige der Aufgaben braucht man durchaus tieferes Wissen in der IT. Wenn du selbst dich nicht in der Lage dazu siehst, such dir jemanden der dich dabei unterstützt. Ich weiß leider weiterhin nicht was deine Intention dabei ist. Vlt. geht es dir auch nur um Absicherung deiner Website, dann würden Sicherheitsplugins vlt. ausreichend sein: https://de.wordpress.org/plugins/tags/security/
-
Diese Antwort wurde vor 1 Monat von
threadi geändert.
-
Diese Antwort wurde vor 1 Monat von threadi geändert.
Ja, richtig, aber in einem TUT könnte man alle tausend Möglichkeiten der Absicherung zusammenfassen, damit auch jeder Hacker weiß, was auf ihn zukommen kann ;-)))))))
P.s.: ich habe da so eine Idee ( s.u. https://********)
-
Diese Antwort wurde vor 1 Monat von
kurt1946 geändert.
-
Diese Antwort wurde vor 1 Monat von kurt1946 geändert.
-
Diese Antwort wurde vor 1 Monat von
La Geek geändert.
Es gäbe noch eine Alternative, die für erheblich mehr Sicherheit sorgt: statische Seiten. Mit Plugins wie Statify kann man sich sein WordPress als statische Dateien erzeugen lassen.
Statify ist ein Statistik-Plugin. Ich weiß nicht, welches Plugin threadi genau im Sinn hatte, mit dieser Suche findet man einige andere: https://de.wordpress.org/plugins/search/static/
Es gibt ja diverse Tools mit welchem man durchsuchen kann, welche Plugins und welches Theme auf einer WordPress-Website zum Einsatz kommt. Gibt die Möglichkeit dies mittels Plugin zu schützen, sodass die Angaben nicht mehr oder nur noch teilweise herausgelesen werden können?
Das ist „security through obscurity“ und hindert bestenfalls Script-Kiddies daran, eine Website zu hacken. Sicherheit durch Verschleierung sichert keine Website wirklich ab. Zum einen können erfahrene Leute immer noch auf den Seitenquelltext und die Developer Tools zugreifen und somit hinweisgebende Scripts, CSS-Dateien und markante Bezeichnungen von HTML-Elementen auslesen und zum anderen lassen Hacker Bots für sich arbeiten, die Websites anhand von IP-Listen scannen und die auch auf Dateistrukturen zugreifen, wie threadi bereits zum Teil erklärt hatte.
Wenn es dir wirklich um Sicherheit geht, dann schau dir folgenden Artikel (mit vielen weiterführenden Links) an:
https://developer.wordpress.org/advanced-administration/security/hardening/
und als Ergänzung noch ein Beitrag von mir: https://software-lupe.de/tipp/kleine-checkliste-fuer-ihre-sicherheit-im-internet/
Bitte an Admin und/oder Moderatoren: bitte diesen Satz in meinem Post und dann anschließend dieses Post hier löschen:
“ P.s.: ich habe da so eine Idee ( s.u. https://******) „
Warum? Ich habe die Site von La Geek besucht 😉
-
Diese Antwort wurde vor 1 Monat von kurt1946 geändert.
-
Diese Antwort wurde vor 1 Monat von kurt1946 geändert.
-
Diese Antwort wurde vor 1 Monat von La Geek geändert.
Danke für eure zahlreichen Rückmeldungen. Ich mache mir Gedanken dazu.
Da seit einiger Zeit keine Rückmeldung mehr vom TE kam, wird der Thread aus administrativen Gründen auf gelöst gesetzt, damit die ungelösten Threads, in denen noch Hilfe benötigt wird, leichter auffindbar sind.
Der Status „gelöst“ kann vom TE jederzeit geändert und der Thread kann mit Nachfragen oder einem Feedback ergänzt werden.
Lösung gefunden? In einem User-helfen-User-Forum wie diesem hier ist das Posten der Lösung für andere User immer hilfreich, danke.
