Posts by SilentAero

    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?

    Ich habe testweise diesen Code im Einsatz.
    Bisher funktioniert er.
    Hinweis: Ich habe hier eine Feed-Sperre gesetzt (wird auf dieser Seite auch nicht genutzt).

    Dies hier würde Ausnahmen zulassen:

    RewriteCond %{HTTP_USER_AGENT} !(Feedly|Feeder|FeedBurner|NetNewsWire|Reeder|Vienna|NewsBlur|Inoreader|Flipboard|Newsbeuter|RSSOwl|QuiteRSS|Strawberry|Akregator|Liferea|FreshRSS|Syndication) [NC]
    RewriteRule .* - [F,L]

    Grundsätzlich sollte man immer prüfen, ob ein Plugin (z. B. Yoast, RankMath, WP Rocket) auf die Feeds zugreift – sonst kann es zu unerwarteten Fehlern im Backend kommen.

    Apache 2.2 / 2.4 Kompatibilität: Im Block 4 ist eine automatische Erkennung integriert: mod_authz_core existiert nur in Apache 2.4. So funktioniert der Code in beiden Versionen, ohne dass etwas angepasst werden muss.

    Erklärung der einzelnen Regeln
    RewriteCond \.php: Matcht jeden Aufruf, der eine Datei mit der Endung .php am Ende innerhalb der angegebenen Plugin-Pfade hat. Verzeichnisse wie wp-content/plugins/elementor/assets/css/ bleiben dadurch erreichbar.
    RewriteRule .* - [F,L]: Sendet einen 403 Forbidden-Statuscode an den Bot, was bedeutet: Du darfst hier nicht rein. Das blockiert den Scanner effizient.
    Globale PHP-Sperre in Uploads: php, phtml, phps, .pl, .py usw. werden pauschal blockiert. Falls ein Bot also versucht, Schadcode als Bild hochzuladen und ihn direkt aufzurufen, bekommt er hier ebenfalls ein 403.

    # ==========================================================
    # WordPress: Direktzugriff auf Skripte
    # (Apache 2.2 / 2.4 kompatibel)
    # ==========================================================

    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /

    # --- 1) Plugin- und Shell-Sperren ---
    RewriteCond %{REQUEST_URI} ^/(wp-content/plugins/elementor|wp-content/plugins/revslider|wp-content/plugins/duplicator|wp-content/plugins/contact-form-7)/.*\.php [NC,OR]
    RewriteCond %{REQUEST_URI} ^/wp-content/plugins/(.*)\.php$ [NC,OR]
    RewriteCond %{REQUEST_URI} ^/wp-content/uploads/shell\.php$ [NC,OR]
    RewriteCond %{REQUEST_URI} ^/wp-content/uploads/marv\.php$ [NC,OR]
    RewriteCond %{REQUEST_URI} ^/wp-content/plugins/fix\.php$ [NC,OR]
    RewriteCond %{REQUEST_URI} ^/wp-includes/js/tinymce/plugins/ [NC,OR]

    # --- 2) Feed-Verzeichnisse schützen ---
    RewriteCond %{REQUEST_URI} ^/(feed|comments/feed)/?$ [NC]

    RewriteRule .* - [F,L]
    </IfModule>

    # --- 3) Globale PHP-Sperre im Upload-Verzeichnis ---
    <IfModule mod_rewrite.c>
    RewriteRule ^wp-content/uploads/.*\.(php|phps|phtml|pl|py|cgi|sh)$ - [F,L]
    </IfModule>

    # --- 4) Konfigurations- und Versionsdateien schützen ---
    <FilesMatch "^(wp-config\.php\.bak|wp-config\.php\.old|wp-config\.php\.txt|wp-config\.php~|wp-config\.bak|readme\.html|license\.txt)$">
    <IfModule mod_authz_core.c>
    Require all denied
    </IfModule>
    <IfModule !mod_authz_core.c>
    Order allow,deny
    Deny from all
    </IfModule>
    </FilesMatch>

    # ==========================================================
    # Ende des Blocks
    # ==========================================================

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

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

    Thanks for starting this discussion!

    Gladly. We can only learn more.

    Habe ich heute wieder was dazu gelernt. Danke euch beiden für eure Ausführungen.

    Gern.
    Ich habe mehrere WordPress-Seiten, die teilweise schon viele Jahre laufen.
    Mit den Spammern und Hackern lege ich mich schon lange an, auch mit Erfolg.
    Aber der Kampf geht nie zu Ende.

    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.
    Ich bin ein Mensch der Praxis und ich sehe da Erfolge, aber wie schon gesagt – es endet nie. ;)

    .htaccess zu verbieten. Hier ein kleines Beispiel dazu:

    Das wird so nicht funktionieren.
    Ich habe einige Erfahrung mit der .htaccess bzw. mit der "Apache Directive Syntax".
    Wenn dieses Tool hier eine WordPress-Seite aufruft, ist der ISP (laut IP): Google Cloud / googleusercontent.com.
    Kein Referer und keine Browserkennung. Interessanterweise versucht das Tool anscheinend: "feed" und "/comments/feed/" aufzurufen.
    Die IP einzeln oder den ganzen CIDR-Block zu sperren, scheint mir so nicht sinnvoll (Google).

    Die Ninja-Firewall scheint diesen Aufruf zu erkennen. Er steht im Log.
    Aber nur als Info: (21/Jul/26 14:15:40 #4836628 INFO - 35.21****** GET / - Sanitising user input -)
    Demnach wurde meine Seite aufgerufen. Merkwürdig ist dennoch, dass das Tool unten einen Screenshot der Seite anzeigt und da
    sehe ich die Ausgabe von der Firewall, wenn sie eine Anfrage blockiert.
    Alles sehr interessant.
    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.



    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.

    Richtig.
    Die Ninja-Firewall ist bei allen meinen Seiten aktiv und aktuell halte ich auch immer alles.
    Wie schon oben geschrieben, ging es mir mehr darum, herauszufinden, wie eine Seite (die mit dem ASTRA-DB-Theme) arbeitet,
    dieses Tool blockieren kann, denn wie schon geschrieben, kann ich mir bei denen nicht vorstellen, dass die WordPress
    ohne nur ein einziges Plug-in nutzen.

    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

    Gut, ich denke, das sollte jedem klar sein und wird von mir auch nicht vernachlässigt.

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

    Auch das wäre mir nicht neu. Ich habe auch nicht behauptet, dass man damit etwas zu 100 % absichern könnte.
    Mir ging es darum, dass eine gewerbliche WordPress-Seite bzw. deren Admins, dies anscheinend vollkommen blockieren können.
    Das WP-Ghost-Plug-in scheint da anzusetzen. Für mich persönlich scheint das Plug-in aber übertrieben.

    Solche Dinge sind Pflichtangaben

    Auch das habe ich nicht angezweifelt. Und nun bitte keine weiteren Kommentare, was die Impressums- und Datenschutzpflichten
    von privat und gewerblich genutzten WordPress-Seiten angeht.
    Dass man u. a. aus diesen Pfaden (/wp-content/plugins/, meta name="generator" content="...", wp_enqueue_script/style)
    viel auslesen kann, ist mir nun klar geworden.

    Moin!

    Ich habe eine Frage an euch:

    Ich bin eher durch Zufall über diesen "WordPress Theme Detector" (Link) gestolpert.
    Das Tool gibt einige Informationen über ein installiertes WordPress aus:

    Quote

    "WordPress Theme Detector is a free tool that allows you to find all the details about
    the WordPress theme and plugins currently being used by a site."

    Was mich etwas beunruhigt: Das Tool listet auch alle installierten Plug-ins auf – so auch bei meinen WordPress-Seiten.
    Das könnte insbesondere bei gewerblichen Seiten problematisch werden, wenn dort z. B. Statistik- oder Datenverarbeitungs-Plugins
    genutzt werden.
    Klar, man könnte oder müsste diese in seiner Datenschutzerklärung auflisten, dennoch habe ich Bedenken, was solche Daten angeht.

    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.

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

    Vielen Dank im Voraus!