WordPress Theme Detector: Plug-in-Erkennung blockieren?

Moin SilentAero,

ich versuche dir mal auf einige deiner Punkte zu antworten.

Zitat von SilentAero

Klar, man könnte oder müsste diese in seiner Datenschutzerklärung auflisten, dennoch habe ich Bedenken, was solche Daten angeht.

Es gibt da kein "man könnte"! Solche Dinge sind Pflichtangaben. Zudem müssen Besucher einer Webseite "gefragt" werden ob sie mit der Verarbeitung ihrer Daten einverstanden sind. Stichwort DSGVO.

Zitat von SilentAero

Was mich etwas beunruhigt: Das Tool listet auch alle installierten Plug-ins auf – so auch bei meinen WordPress-Seiten.

Was beunruhigt dich daran? Abseits solcher Tools findet man das anhand des Quelletextes eigentlich immer raus. Laien wird es durch bestimmte Tools nur erschwert.

Zitat von SilentAero

Kennt ihr Möglichkeiten, die Abfrage solcher Tools zu blockieren?

Es gibt Plugins die so etwas verhindern sollen. Zum Beispiel dieses hier: Link

Wobei ich persönlich solche Tools eher suboptimal finde. Damit kann man sehr viel kaputt machen wenn man solche Plugins zu sehr ins System eingreifen lässt. Kompatibilität mit diversen Plugins (Member-Plugins etc.) mal außen vor gelassen. Viel wichtiger etwas verschleiern zu wollen, ist es für mich WordPress vernünftig abzusichern. Starke Passwörter, WordPress, Themes und Plugins immer möglichst aktuelle halten etc. WordPress selbst bietet da auch eine Reihe von Möglichkeiten wie man seine Seite sicherer machen kann. Da spielen viele Faktoren eine Rolle. Nicht nur WordPress selbst. Siehe dazu: Hardening WordPress .

Die wirklich "bösen Buben" hält eine Verschleierung bestenfalls etwas auf, schützt aber nicht wirklich. 😎

Moin SilentAero,

da ich nicht wusste/weiß welche Vorkenntnisse du hast, habe ich einige Dinge allgemein beantwortet.

Ein praktischer Lösungsansatz (ungetestet):

Man kann auch versuchen den Zugriff solcher Referrer-URLs via .htaccess zu verbieten. Hier ein kleines Beispiel dazu:

RewriteEngine on
    RewriteCond %{HTTP_REFERER} ^https?://([^.]+\.)*wpthemedetector\.com\ [NC,OR]
    RewriteCond %{HTTP_REFERER} ^https?://([^.]+\.)*weiteredomaindiegeblocktwerdensoll\.de\ [NC,OR] 
RewriteRule .* - [F,L]

Oder:

SetEnvIfNoCase Referer "wpthemedetector.com" kein_zugriff
Order Allow,Deny
Allow from ALL
Deny from env=kein_zugriff

Einfach einen solchen Block mal in die .htaccess einbauen und schauen ob die von dir genannte Seite dann geblockt wird. Vielleicht hilft das ja schon. Ist eben ungetestet und nur ein Gedankenspiel meinerseits.

Solche Blockierungen bereiten auch mehr Mühe als es sich lohnt. Es gibt sehr viele derartige Tools, willst du alle aussperren? Das geht faktisch nicht, weil es keine komplette Liste gibt und diese sich auch (ähnlich wie KIs) laufend ändert.

Und wie schon geschrieben, ist es sehr leicht anhand des Quellcodes oder auch der REST API und anderen Dingen herauszubekommen, wie ein Projekt konfiguriert ist. Per se ist das auch gar kein Sicherheitsproblem für das Projekt. Bots, die Angriffe laufen lassen, gucken gar nicht nach sowas sondern hacken einfach drauf los - und stoßen, wenn eine vermeintliche Lücke doch nicht existiert, halt auf einen Fehler und versuchen das nächste. Die gucken nicht nach "was ist". Aus dem Grund hilft auch jegliche Anonymisierung/Pseudonomisierung der Website imho nichts.

Ich würde mir daher darüber gar nicht so viele Gedanken machen. Wichtiger ist, dass du deine Projekte regelmäßig aktualisierst und ein Sicherheitsplugin oder vorgeschaltete Firewall im Einsatz hast um Angriffe abzuwehren.

Werkzeuge wie WPThemeDetector, RSS-Aggregatoren oder Sicherheits-Scanner nutzen bevorzugt Google Cloud-Server. Das ist oftmals für das Thema Preisgünstiger. Sie steuern gezielt WordPress Pfade wie zB. /feed/ oder /comments/feed/ an, um im XML-Quellcode nach Versionsnummern, Themes und Plugins zu suchen. Dass weder User Agent noch Referer mitgesendet werden, zeigt, dass hier ein recht simples Skript ohne Browser-Emulation am Werk ist.

Komplette Google Cloud IP Bereiche per .htaccess zu blockieren, schießt über das Ziel weit hinaus und trifft schnell die falschen Dienste. Sauberer wäre es, Anfragen ohne User Agent gezielt abzulehnen oder ungenutzte WordPress Feeds direkt serverseitig abzuschalten.

Zitat

Nun ist mir aufgefallen, dass bei einer gewerblichen Seite eines Anbieters, der auch YouTube-Videos zu technischen Themen anbietet,
keine Plug-ins aufgelistet werden. Ich kann mir nicht vorstellen, dass auf einer Seite von Programmierern 0 (Null) Plug-ins installiert sein sollen.

Du könntest die normalen Pfade via .htaccess auf neutale Namen umleiten oder die Versionsnummern und Meta Tags via der functions.php strippen. Alternativ baust du dir ein Plugin selbst. So kommst du für extern zu Null Plugins.

Zitat

Ich werde die nächsten Tage mal versuchen herauszufinden, ob ich die einzelnen Pfade wie z. B.: "wp-content/plugins/" per .htaccess von
außen sperren kann.

Sperrst du den Ordner /wp-content/plugins/ per .htaccess komplett für externe Aufrufe, kann der jeweilige User Browser vorhandene css und JS Dateien nicht mehr laden. Deine Website sieht optisch, sagen wir mal kaputt aus und viele Skripte funktionieren nicht mehr. Der Browser ist in diesem Fall außen. Sinn?

Zitat von SilentAero

Ich kann mir nicht vorstellen, dass auf einer Seite von Programmierern 0 (Null) Plug-ins installiert sein sollen.

Wenn ich alles individuell code und keinen 3rd Party Stuff von der Stange nutze, was soll da aufgelistet werden?

SilentAero  Baldini

Ich hab mich nie mit solchen Seiten beschäftigt. Mein Tipp mit der .htaccess ist dann natürlich obsolet weil es nicht funktioniert. Habe ich heute wieder was dazu gelernt. Danke euch beiden für eure Ausführungen.

SilentAero

WordPress kenne ich auch "ein wenig". 😉

Die Arbeits- bzw. Funktionsweise solcher "Scanner-Seiten" sind mir aber recht neu, weil ich mich nie damit beschäftigt habe. Solltest du eine Lösung zu deinem Problem finden veröffentlichst du das hoffentlich auch hier?

Zitat von SilentAero

Ich zeige dir hier nur mal einen kleinen Ausschnitt von einer meiner .htaccess-Dateien.
Aber bitte keine Diskussionen, ob dies so sinvoll ist oder nicht.

Sicherheitsmaßnahmen sind bzw. können oftmals sehr individuell sein. Von daher gibt es von meiner Seite da eigentlich nie Diskussionen. Ich selber habe auch für viele Seiten eine stark angepasste .htaccess.

Zitat von SilentAero

Wer macht sich die Arbeit, viele Funktionen, die sonst in Plug-ins realisiert werden, als "individuell code" selber zu schreiben?

Derjenige der sich von der Masse abheben will.
Es macht Sinn, denn händische Arbeit sieht Google und Konsorten schon.