Willkommen beim WP Wegerl.at 'Lesemodus' + Tastaturnavigation!
Entspanntes Lesen und spannende Artikel warten auf dich.
Entdecke unsere besten Beiträge und genieße den Lesemodus sowie die Tastaturbedienung.
WP Wegerl.at: Einzigartige Designs, optimiert für das Nutzererlebnis.
Security, NinjaFirewall WP
smilies.4-user.de

WP Security! – NinjaFirewall

Werbung

Der Classic-Editor: Vertraut und zuverlässig –
Ihr bewährter Begleiter.


Erleben Sie den Classic Editor neu!
(Bilder von pixelcreatures)


Viele Nutzer schätzen die vertraute Umgebung des Classic-Editors, die eine einfache und schnelle Bearbeitung ermöglicht.




Werbung

Mit dem Advanced Editor Tools auf das nächste Level –
Mehr Funktionen, mehr Möglichkeiten.


Classic Editor + Advanced Editor Tools
= Ihr Erfolgsrezept


Der Advanced Editor erweitert den Funktionsumfang des Classic-Editors und ermöglicht es, Inhalte noch effektiver zu bearbeiten.




Werbung

Einfach und intuitiv –
Der Classic-Editor für alle.


Classic Editor & Advanced Editor Tools
Erleben Sie es.


Der Classic-Editor zeichnet sich durch Stabilität und Zuverlässigkeit aus, was für professionellen Anwender von Bedeutung ist.




Werbung

Mehr schaffen in weniger Zeit –
Der Advanced Editor für kreative Köpfe.


Optimieren Sie Ihre Bearbeitung:
Advanced Editor Tools


Mit dem Advanced Editor können Designer und
Content Creatoren kreative Ideen umsetzten.





Hallo, zur Security von WordPress-Sicherheit und speziell zum Plug-in 'NinjaFirewall'. Eine Firewall ist für die Sicherheit von WordPress-Installationen äußerst wichtig und NinjaFirewall ist eine eigenständige Web Application Firewall, die jede HTTP- und HTTPS-Anforderung, die an ein PHP-Skript gesendet wird, scannt, ablehnt oder bereinigt, bevor es WordPress oder eines seiner Plug-ins erreicht. Obwohl es wie ein Plug-in aussieht und sich anfühlt, ist es eigentlich keine einfache Erweiterung. Insgesamt bietet es einen ausgezeichneten Schutz für Ihre Website.

Voranstellend! – Sicherheit und Shared-Webhosting-Services

Zunächst einmal zum Thema WordPress-Sicherheit und Shared-Webhosting-Services.

Bei Shared-Webhosting-Services ist das Server-Management in der Regel inklusive, einschließlich der Sicherheit im Hosting-Bereich. Wenn Sie sich also fragen, wie das genau zu verstehen ist, sollten Sie diese Frage an Ihren Host richten.

Fragestellung an Web-Host-Server bplaced
Ich habe das Plug-in NinjaFirewall auf meiner Website installiert, um WordPress abzusichern. Nun frage ich mich, ob es notwendig ist, solche Plug-ins auch bei Shared-Hosting-Services zu verwenden, da der Web-Host-Server bplaced das gesamte Management inklusive Sicherheit beinhaltet.

Die Antwort …
Das Plug-in ist soweit auf einer anderen Ebene. Sicherheitsplugins wie NinjaFirewall bieten einen spezifischen Schutz auf der Ebene der WordPress-Installation und kann zusätzliche Sicherheitsebenen bieten, zur abwehr von Bots usw. Während wir für die Sicherheit des Servers sorgen, fokussiert sich NinjaFirewall auf WordPress-spezifische Bedrohungen, insbesondere durch Funktionen wie Web Application Firewall (WAF), die bestimmte Arten von Angriffen auf PHP-Ebene abblocken können. Dies ergänzt die Sicherheitsvorkehrungen auf Serverebene, … kann also bleiben.

Sicherheitsplugins wie NinjaFirewall sind eine sinNvolle Ergänzung, auch in einem Shared-Hosting-Umfeld.

NinjaFirewall. – Was kann das Security Plug-in?

NinjaFirewall (WP Edition) – Advanced Security Plugin and Firewall

Das Plug-in NinjaFirewall gilt als Geheimtipp unter den Security-Plug-ins. Die Installation ist etwas komplizierter, aber das Plug-in bietet umfangreiche Sicherheitsfunktionen. Die Daten werden auf dem eigenen Webspace gespeichert und nicht an anderer Stelle. Wir haben bisher keine Probleme festgestellt.

NinTechNet, der Hersteller, hält sich nach eigener Aussage strikt an die WordPress Plug-in Developer Guidelines. Die Software NinjaFirewall (WP Edition) ist kostenlos, Open Source und voll funktionsfähig. Es ist keine "Testversion" und es ist nicht erforderlich, einen Registrierungsprozess oder einen Aktivierungsschlüssel zu installieren oder zu verwenden. Laut NinTechNet werden keine Benutzerdaten gesammelt und es wird nicht nach Hause telefoniert.

NinjaFirewall schützt alle Skripte, die sich in den Verzeichnissen und Unterverzeichnissen der WordPress-Installation befinden, einschließlich solcher, die nicht Teil des WordPress-Pakets sind. Auch selbst codierte PHP-Skripte, potenzielle Backdoors und Shell-Skripte werden von NinjaFirewall gefiltert. Ausführlicher folgt das weiter Unterhalb unter Full-WAF-Mode ↓. Das macht das Plug-in zu einer echten Firewall und wahrscheinlich zu einer der stärksten Sicherheitsanwendungen für WordPress.

  • NinjaFirewall arbeitet auf der Ebene des PHP-Interpreters, was bedeutet, dass es in der Lage ist, direkt mit dem PHP-Code der WordPress-Installation zu interagieren. Es kann bestimmte Anfragen oder Aktionen auf PHP-Ebene überwachen und blockieren, um Sicherheitsmaßnahmen umzusetzen. Dies ermöglicht es, Angriffe abzuwehren, bevor sie tief in den WordPress-Code eindringen.

Migrieren der Website und Ninja Firewall

Sie müssen vorsichtig sein.

Migrieren Sie NICHT Ihre Website mit installierter NinjaFirewall. Stattdessen exportieren Sie die Konfiguration, deinstallieren Sie NinjaFirewall und migrieren Sie Ihre Website. Nach dem Migrieren installieren Sie NinjaFirewall neu und importieren Sie die Konfiguration. Das geht alles über das Dashboard.

Die Installation

Sichern Sie vor der Installation bitte Ihr WordPress-Verzeichnis und die WordPress-MySQL-Datenbank. Sollte etwas komplett kaputt gehen, können Sie so wieder auf einen funk­tions­fä­higen Stand zugreifen.

Sichern Sie vor der Installation das WordPress-Verzeichnis und die WordPress MySQL-Datenbank.

Wählen Sie im Dashboard den Menüpunkt 'Plugins' aus. Klicken Sie danach auf den In­stal­lie­ren-Button und suchen nach NinjaFirewall. Auswählen und installieren. Nach dem installieren und aktivieren des Plug-in wird im Admin-Dashboard ein neuer Me­nü­punkt „NinjaFirewall“ angezeigt und es werden verschiedene Auswahlmöglichkeiten für die endgültige Installation abgefragt.

Während der Installation erstellt NinjaFirewall die Datei php.ini mit einem eigenen Eintrag in Ihrem wordpress-Verzeichnis. Diese zusätzliche php.ini Anweisung bewirkt, dass jede An­fra­ge auf Ihrer Website abgefangen und die An­for­de­rungen und der Verkehr mit umfangreichen Regeln (und einer Whitelist) gefiltert werden. Um „gute” Anfragen von bösartigen zu trennen. Die „schlechten” Anfragen werden gelöscht, wäh­rend normale Anfragen an Ihre WordPress Website weitergeleitet werden. Das Ziel ist eine Brandmauer, die verhindert, dass die Web­site gehackt wird.

Wenn Sie bei einem Webhoster ganz normalen Webspace Paket gemietet haben, haben Sie eventuell keinen Zugriff auf die php.ini von PHP. Die php.ini können Sie per SFTP deshalb auch nicht finden.

Wenn während Ihrer Installation andere Dinge abgefragt / angezeigt werden, kann das auch an einer neueren Version (neuer als 3.6) oder an einer anderen Server-Umgebung liegen.

  • NinjaFirewall fragt, ob die Installation im Full-WAF-Mode oder im WordPress WAF mode durchgeführt werden soll.

Zunächst klären wir die Begriffe WordPress WAF-Mode und Full-WAF-Mode. Bevor wir in die Details dieser Sicherheitsmodi eintauchen, werfen wir einen Blick auf den zentralen Akteur in diesem Zusammenhang: den PHP-Interpreter. Um die Beziehung zwischen dem PHP-Interpreter und einer Web Application Firewall (WAF) zu erklären, schauen wir uns zunächst die beiden Konzepte genauer an:

PHP-Interpreter und Web Application Firewall (WAF)

PHP-Interpreter: Der PHP-Interpreter ist ein Programm, das PHP-Code ausführt und ihn in Anweisungen für den Computer übersetzt, also für die Ausführung von PHP-Code auf einer Website verantwortlich ist. In WordPress ist PHP die Skriptsprache, in der Themes und Plugins geschrieben sind. Der Interpreter übersetzt diesen PHP-Code in Anweisungen, die vom Server ausgeführt werden, um dynamische Inhalte zu generieren.

  • In Bezug auf WordPress agiert der PHP-Interpreter auf der Serverseite, um dynamische Inhalte zu erzeugen und die Logik von WordPress-Plug-ins und -Themes zu verarbeiten.

Der PHP-Interpreter interpretiert das PHP
– entschlüsselt die Essenz des Codes –
Dein Code, seine Sprache, unsere Ausführung.

Die Verbindung zwischen PHP-Interpreter und WAF besteht darin, dass eine WAF auf der Ebene des HTTP-Verkehrs agiert, bevor dieser den PHP-Interpreter erreicht. Hier sind einige Aspekte, wie sie zusammenarbeiten:

WordPress WAF-Mode: Der WordPress WAF-Mode ist eine spezifische Sicherheitsmaßnahme innerhalb von WordPress, die auf PHP-Ebene agiert. Er überwacht und analysiert nur HTTP-Anfragen (nicht HTTPS) und blockiert potenzielle Angriffe auf der Ebene des PHP-Interpreters. Dieser Modus bietet eine grundlegende Sicherheitsschicht speziell für WordPress-spezifische Bedrohungen.

Full Web Application Firewall (Full-WAF)-Mode: Im Gegensatz dazu arbeitet der Full-WAF-Mode auf einer umfassenderen Ebene. Er analysiert den gesamten HTTP- und HTTPS-Datenverkehr zwischen dem Webserver und den Benutzern. Dieser Modus erkennt potenzielle Angriffe auf einer höheren Ebene, bevor sie den PHP-Interpreter erreichen. Durch das Blockieren bekannter Angriffsmuster und die Überwachung verschiedener Schichten des Webverkehrs bietet der Full-WAF-Mode einen umfassenderen Schutz für die gesamte Webanwendung.

  • Zusammengefasst ergänzt eine Full-WAF den Schutz auf der Ebene des PHP-Interpreters, indem sie auf einer höheren Ebene agiert und eine umfassendere Verteidigung gegen verschiedene Webangriffe bietet.

Zusammenarbeit mit dem PHP-Interpreter: Beide Modi, sowohl der WordPress WAF-Mode als auch der Full-WAF-Mode, arbeiten mit dem PHP-Interpreter zusammen. Der WordPress WAF-Mode konzentriert sich speziell auf die PHP-Verarbeitung von HTTP-Anfragen, während der Full-WAF-Mode auf einer höheren Ebene agiert und sowohl HTTP- als auch HTTPS-Anfragen überwacht. Diese beiden Modi ergänzen sich, indem sie auf unterschiedlichen Ebenen des Webverkehrs angreifen und zusammen eine umfassende Verteidigung gegen verschiedene Arten von Angriffen bieten.

Der Nutzen des Full-WAF-Modus trotz HTTPS:
Warum eine sichere Verbindung allein nicht ausreicht

Der Hauptunterschied zwischen HTTP (Hypertext Transfer Protocol) und HTTPS (Hypertext Transfer Protocol Secure) liegt in der Sicherheit:

  1. HTTP (Hypertext Transfer Protocol):
    • Nicht sicher: HTTP überträgt Daten zwischen dem Webserver und dem Browser des Benutzers in Klartext. Das bedeutet, dass alle übermittelten Informationen, einschließlich sensibler Daten wie Anmeldeinformationen, ohne Verschlüsselung sichtbar sind. Dies macht HTTP anfällig für Man-in-the-Middle-Angriffe, bei denen ein Angreifer den Datenverkehr abfangen und lesen kann.
  2. HTTPS (Hypertext Transfer Protocol Secure):
    • Sicher: HTTPS hingegen bietet eine verschlüsselte Verbindung zwischen dem Webserver und dem Browser des Benutzers. Diese Verschlüsselung wird durch SSL/TLS-Protokolle bereitgestellt und gewährleistet, dass die übermittelten Daten sicher sind und nicht von Dritten eingesehen werden können. HTTPS schützt die Vertraulichkeit und Integrität der übertragenen Informationen.
  3. Verschlüsselung und Zertifikate:
    • Bei HTTPS wird eine SSL/TLS-Verschlüsselung verwendet, um sicherzustellen, dass die Daten während der Übertragung geschützt sind. Websites, die HTTPS verwenden, benötigen ein SSL/TLS-Zertifikat, das von einer vertrauenswürdigen Zertifizierungsstelle ausgestellt wird. Dieses Zertifikat bestätigt die Echtheit der Website und stellt sicher, dass die übertragene Information privat bleibt.

Insgesamt bietet HTTPS eine sicherere Übertragung von Daten im Vergleich zu HTTP. Websites, die persönliche oder vertrauliche Informationen verarbeiten, sollten HTTPS verwenden, um die Sicherheit und Privatsphäre der Benutzer zu gewährleisten. In der heutigen Zeit wird die Verwendung von HTTPS zunehmend empfohlen und ist in vielen modernen Websites Standard.

Auch wenn bereits eine HTTPS-Verbindung verwendet wird, bietet der Full-WAF-Mode immer noch entscheidende Vorteile in Bezug auf Sicherheit und Schutz. Hier sind einige Gründe, warum der Full-WAF-Mode auch für HTTPS-Verbindungen von Nutzen sein kann:

  1. Schutz auf Anwendungsebene:
    • Der Full-WAF-Mode schützt nicht nur vor Bedrohungen auf der Transportebene (wie Man-in-the-Middle-Angriffen), sondern vor allem auf der Anwendungsebene. Er erkennt und blockiert spezifische Angriffsmuster, die auf Webanwendungen abzielen, unabhängig von der Verschlüsselung des Datenverkehrs.
  2. Erkennung von Angriffen:
    • Ein Full-WAF analysiert den gesamten HTTP- und HTTPS-Datenverkehr, um verdächtige Aktivitäten und Angriffe zu identifizieren. Dies umfasst nicht nur den Inhalt der Übertragung, sondern auch die Struktur der Anfragen und Antworten. So können bestimmte Angriffsszenarien erkannt und abgewehrt werden.
  3. Bot-Schutz:
    • Full-WAF-Systeme sind oft in der Lage, zwischen legitimen Benutzern und bösartigen Bots zu unterscheiden. Auch wenn du eine sichere HTTPS-Verbindung verwendest, schützt dich der Full-WAF-Mode vor automatisierten Angriffen, Skripten und Bots, die versuchen, Schwachstellen deiner Website auszunutzen.
  4. Vollständige Webanwendungssicherheit:
    • Durch die umfassende Überwachung des gesamten Datenverkehrs bietet der Full-WAF-Mode eine zusätzliche Schicht der Webanwendungssicherheit. Dies ist besonders wichtig, wenn deine Website komplexe Anwendungen oder Interaktionen mit Benutzern beinhaltet.

Insgesamt erhöht der Full-WAF-Mode die Sicherheitsstufe einer Website, indem er nicht nur die Transportebene, sondern vor allem die Anwendungsebene schützt. Dies ist besonders wichtig, da viele Angriffe, wie SQL-Injektionen oder Cross-Site-Scripting, auf der Anwendungsebene abzielen. Daher ist es ratsam, den Full-WAF-Mode zu aktivieren, selbst wenn bereits eine HTTPS-Verbindung vorhanden ist.

Full-WAF-Modus mit einer HTTP-Verbindung

Der Full-WAF-Modus kann auch mit einer HTTP-Verbindung verwendet werden, und in der Tat kann dies die Sicherheit von HTTP verbessern. Der Hauptzweck eines Web Application Firewalls (WAF) besteht darin, Webanwendungen vor verschiedenen Arten von Angriffen zu schützen, unabhängig davon, ob die Verbindung über HTTP oder HTTPS erfolgt.

Es ist jedoch zu beachten, dass HTTPS weiterhin als sicherere Option gilt, da es den verschlüsselten Datentransfer zwischen dem Webserver und dem Benutzer gewährleistet. Wenn möglich, wird die Verwendung von HTTPS immer empfohlen, insbesondere wenn sensible Informationen übertragen werden. Der Full-WAF-Modus kann jedoch auch die Sicherheit von reinen HTTP-Verbindungen verbessern.

WordPress WAF-Mode

WAF ist eine Web Application Firewall oder Web Schild, ein Verfahren, das Webanwendungen vor Angriffen über das Hypertext Transfer Protocol (HTTP) schützen soll. S. Web Application Firewall.

Der WordPress WAF Modus erfordert das Laden von NinjaFirewall über das WordPress wp-config.php Skript. Dieser Prozess macht es einfach zu installieren und die Installation wird immer erfolgreich sein, unabhängig von den Einschränkungen Ihres Hostingplans. NinjaFirewall wird noch vor WordPress, seinen Plug-ins und der Datenbank geladen und läuft genauso schnell wie der Full-WAF-Modus.

Der Nachteil dieses Modus ist, dass NinjaFirewall nur HTTP-Anfragen an WordPress abfangen und filtern kann. Einige Funktionen wie File Guard, URL Access Control und Web Filter (nur WP+ Edition) sind eingeschränkt. Obwohl er weniger leistungsfähig ist als der Full-WAF-Modus, bietet er dennoch ein höheres Schutzniveau und eine höhere Leistung als jedes andere Sicherheitsplugin.

Full-WAF-Mode

Der Full-WAF-Mode (Web Application Firewall) ist eine umfassende Sicherheitsmaßnahme, der die Website vor einer Vielzahl von Bedrohungen schützen kann, indem sie potenziell schädlichen Datenverkehr filtert und blockiert. Dieser Modus greift normalerweise auf einer tieferen Ebene in den Datenverkehr der Website ein und kann mehr Schutz gegen spezifische Angriffstypen bieten.

Im Full-WAF-Mode überwacht die Firewall den gesamten eingehenden und ausgehenden Datenverkehr. Das betrifft nicht nur die REST-API und andere API-Verbindungen, sondern auch sämtlichen Traffic, der die Website erreicht, einschließlich HTTP- und HTTPS-Anfragen sowie andere Arten von Anfragen an den Server. NinjaFirewall wird jede HTTP und HTTPS Anfrage, die an ein PHP Skript gesendet wird, abfangen, scannen, ablehnen oder sanitisieren, bevor sie WordPress, seine Plug-ins oder sogar die Datenbank erreicht.

Alle Skripte, die sich in den Blog-Installationsverzeichnissen und Unterverzeichnissen befinden, werden geschützt, auch solche, die nicht Teil des WordPress-Pakets sind. Selbst verschlüsselte PHP Skripte (z.B. ionCube), potentielle Backdoors und Shell Skripte (z.B. c99, r57) werden von der Firewall gefiltert. – Security.

Das macht NinjaFirewall zu einer echten Firewall und gibt das höchstmögliche Maß an Schutz: Sicherheit ohne Kompromisse. Um NinjaFirewall im Full-WAF-Modus zu betreiben, muss der Server die Verwendung der auto_prepend_file PHP Direktive erlauben.

PHP Direktive auto_prepend_file wird benötigt, um den PHP-Interpreter anzuweisen, die Firewall vor WordPress oder einem anderen Skript zu laden. In den meisten Fällen funktioniert dies sofort, oder es sind nur einige kleine Anpassungen erforderlich. Aber in einigen wenigen Fällen, vor allem wegen der Beschränkungen einiger Shared-Hosting-Angebote, kann es eventuell nicht funktionieren.

Installation des Full-WAF-Mode

Wir empfehlen, zunächst die Option Full-WAF Mode zu wählen. Sollte dies nicht gelingen, können Sie mit diesem Installationsprogramm problemlos zum WordPress-WAF-Modus wechseln.

Folgende Dinge sollten vorab mit dem Provider geklärt werden:

  • Welcher HTTP-Server und welche PHP Server API verwendet der Provider für Ihre Domain?
  • Welche *.ini wird für das PHP Ihrer Domain verwendet – php.ini, .php.ini user.ini oder php5.ini?
Plug-in NinjaFirewall und
der Full-WAF mode

Damit NinjaFirewall anstatt WAF-WP-Modus  im vollständigen WAF-Modus ausgeführt werden kann, muss der Server die Verwendung der PHP-Direktive auto_prepend_file zulassen.

Wenn ich den Schutz schon installiere, dann will ich auch so viel Schutz wie möglich.

Betreff Full-WAF-Mode: Für Plug-in NinjaFirewall zum vollständigen WAF-Modus würde die PHP-Direktive auto_prepend_file gebraucht. Meine Frage: Ist das hier über das Webhosting möglich?

Host-Support: Dem sollte nichts im Wege stehen. Die Regel auto_prepend_file ist in der PHP-Installation standardmässig auf no value gestellt. S. auch phpinfo.bplaced.net.

Du kannst da selbst eine .php.ini Datei erstellen (der Punkt vor dem PHP ist wichtig, denn so wird sie als Systemdatei erkannt). Das mit dem Eintrag:

php_value auto_prepend_file on

… und in das Webseitenverzeichnis – also in den Ordner www – uploaden. Auf dem Webspace sollte nach Minuten die Funktion aktiv sein.

NinjaFirewall: Die Konfiguration

Bevor wir uns hier weiter mit der Konfiguration befassen, möchte ich auf den Artikel von NinjaFirewall mit dem Titel "WordPress mit einer Web Application Firewall sichern: NinjaFirewall (WP Edition)", mit diesem Link hinweisen.

Das Folgende wurde in Zusammenarbeit mit ChatGPT erarbeitet und unterscheidet sich in der Formatierung vom obigen Linkhinweis und weicht in der Informationsfülle ab. Mir war es ein Anliegen, dies Punkt für Punkt zu überarbeiten. Vielen Dank für dein Verständnis! – und ich lade dich gern ein, mir hier zu folgen.


NinjaFirewall hat eine Reihe von Regeln, nach denen es funktioniert. Diese Regeln sind meist Zeichen oder Signaturen von Angriffen, die es zu verhindern versucht. Gemäß der Dokumentation werden die Regeln stündlich aus dem WordPress.org-Repository heruntergeladen (konfigurierbar auch abschaltbar), um auf weltweit erkannte Bedrohungen zu reagieren. Das Plug-in kontaktiert die NinTechNet-Server während des Aktualisierungsvorgangs nicht.

Nachdem im NinjaFirewall "Dashboard" der 'Full-WAF-Mode' konfiguriert ist und unter "Firewall Options" die 'Firewall protection' aktiviert wurde, kommen wir zu den verschiedenen Einstellungen der "Firewall Policies" (Firewall-Richtlinien).

Firewall Policies / 3 Tabs

Die Firewall -Richtlinien sind in drei Tabs unterteilt:

Tab 1: Basic Policies
Tab 2: Intermediate Policies
Tab 3: Advanced Policies

Basic Policies

Basic Policies – Grundlegende Richtlinien

SecurityDer Default-Wert, der sowohl HTTP als auch HTTPS abdeckt, ist oft die empfohlene Einstellung. Hier sind einige Gründe dafür:

  1. Ganzheitlicher Schutz: Wenn NinjaFirewall für HTTP und HTTPS aktiviert ist, schützt es deine Website unabhängig davon, wie Besucher darauf zugreifen. Das bedeutet, dass egal ob die Verbindung unverschlüsselt (HTTP) oder verschlüsselt (HTTPS) ist, die Sicherheit gewährleistet ist.
    • Wenn Besucher auf verschiedene Teile der Website über verschiedene Protokolle zugreifen, kann die Aktivierung beider Optionen die Benutzererfahrung verbessern, indem ein einheitlicher Schutz geboten wird, ohne dass Besucher sich Gedanken über die Art der Verbindung machen müssen.
  2. Umfassende Abdeckung: Einige Teile deiner Website könnten über HTTP und andere über HTTPS bedient werden. Indem du NinjaFirewall für beide aktivierst, gewährleistest du, dass sämtlicher Traffic abgedeckt ist.
  3. Konsistenz im Schutz: Die Konfiguration von Sicherheitsmaßnahmen für beide Protokolle (HTTP und HTTPS) gewährleistet eine konsistente Sicherheitspolitik. Das hilft dabei, mögliche Schwachstellen in jedem Teil der Website zu minimieren, unabhängig davon, wie die Verbindung hergestellt wird.

Es ist wichtig zu verstehen, dass diese Einstellungen je nach den individuellen Anforderungen einer Website und dem spezifischen Sicherheitsbedarf variieren können. Im Allgemeinen bietet die Aktivierung für beide Protokolle jedoch eine umfassende und konsistente Sicherheitsabdeckung.


Die weiteren Einstellungen sind sehr individuell und sind recht selbsterklärend.

Insbesondere sind aber die Hinweise zur REST-API und API zu berücksichtigen. Die vorgegebenen Grundeinstellungen sind generell eine gute Wahl.

Die REST-API und die XML-RPC-API sind beide Methoden für die Kommunikation zwischen verschiedenen Systemen oder Diensten und deiner WordPress-Website. Beide APIs ermöglichen es anderen Diensten oder Anwendungen, mit deiner Website zu interagieren, Daten abzurufen oder zu übertragen.

Wenn det Zugriff auf die REST-API deaktivierz wird, könnten bestimmte Funktionen oder Plug-ins auf der Website, die diese API nutzen, beeinträchtigt werden. Das Gleiche gilt auch für die XML-RPC-API. Beide APIs spielen eine wichtige Rolle für verschiedene Plugins und Funktionen, einschließlich des Gutenberg-Editors, Jetpack, Contact Form 7 und anderen.

Die Entscheidung, ob diese APIs aktiviert oder deaktiviert, hängt von den Sicherheitsanforderungen und den Funktionen ab, die auf der Website erforderlich sind. Es ist wichtig zu beachten, dass das Deaktivieren dieser APIs einige Funktionen beeinträchtigen kann, die auf ihrer Verwendung basieren.

Tab 2: Intermediate Policies

Interm. Policies

Intermediate Policies – Mittlere Richtlinien

Hier geht es um die:

HTTP GET variable

Scan GET Variable" und "Sanitize GET Variable" sind Sicherheitsfunktionen und dienen dazu, Anfragen und Daten, die über die GET-Methode gesendet werden, zu überwachen und zu schützen.

  1. Scan GET Variable: Diese Funktion ermöglicht dem Sicherheits-Plug-in das Überwachen und Analysieren von Daten, die über GET-Parameter an die Website gesendet werden. GET-Variablen sind Teil der URL und können von Benutzern eingefügt werden. Das Plug-in scannt diese Variablen auf mögliche Anzeichen von Angriffen, schädlichem Code oder verdächtigen Inhalten.
  2. Sanitize GET Variable: "Sanitizing" bezieht sich auf den Prozess des Reinigens oder Filterns von Daten, um sicherzustellen, dass sie frei von schädlichem Code oder potenziell gefährlichen Inhalten sind. Diese Funktion filtert und bereinigt die über GET-Parameter gesendeten Daten. Sie entfernt potenziell gefährlichen Code oder versucht, schädliche Eingaben zu neutralisieren, um Sicherheitsrisiken zu minimieren.

Es wird empfohlen, diese Funktionen zu aktivieren, um die Sicherheit der Website zu erhöhen, insbesondere wenn die Website öffentlich zugänglich ist und Benutzer über Formulare oder URLs interagieren können. Durch die Überwachung und Bereinigung von GET-Variablen können potenzielle Sicherheitslücken minimiert und Angriffe wie Injection-Angriffe (z. B. SQL-Injection) oder Cross-Site-Scripting (XSS) abgewehrt werden.

Es ist jedoch wichtig zu beachten, dass die Aktivierung dieser Funktionen möglicherweise dazu führen kann, dass einige spezifische Funktionen oder Anwendungen auf der Website nicht wie erwartet funktionieren. Es ist ratsam, die Auswirkungen auf die Website zu überwachen, nachdem diese Funktionen aktiviert wurden.

HTTP POST variable

HTTP POST-Variablen sind Daten, die über das POST-Verfahren an eine Webseite oder Anwendung gesendet werden. Im Gegensatz zu GET-Variablen, die in der URL sichtbar sind, werden POST-Variablen über das HTTP-Body gesendet und sind daher nicht direkt sichtbar.

Die Funktionen "Scan POST Variable" und "Sanitize POST Variable" in einem Security-Plug-in dienen ähnlichen Zwecken wie bei den GET-Variablen:

  1. Scan POST Variable: Diese Funktion überwacht und analysiert Daten, die über POST-Requests an die Webseite gesendet werden. POST-Variablen können genutzt werden, um Daten von Formularen oder anderen interaktiven Elementen zu übertragen. Das Plug-in scannt diese Variablen auf potenzielle Anzeichen von Angriffen oder schädlichem Code.
    • Das Aktivieren der Funktionen für Scan POST-Variable ist ebenfalls empfehlenswert, um Sicherheitsrisiken zu minimieren. POST-Daten können sensible Informationen enthalten und werden oft für Interaktionen wie das Einreichen von Formularen verwendet.
  2. Sanitize POST Variable: Ähnlich wie bei der "Sanitize GET Variable"-Funktion reinigt und filtert diese Funktion die über POST-Variablen gesendeten Daten. Sie entfernt potenziell gefährlichen Code oder neutralisiert schädliche Eingaben, um die Sicherheit der Webseite zu verbessern. "Aktivieren Sie diese Option nur, wenn Sie wissen, was Sie tun!"
    • Es ist wichtig zu beachten, dass diese Sicherheitsmaßnahmen die Funktionalität von bestimmten Formularen oder Interaktionen beeinträchtigen können. Es ist ratsam, nach der Aktivierung dieser Funktionen die Funktionalität der Webseite zu überwachen und gegebenenfalls Anpassungen vorzunehmen.

Die Überwachung und Bereinigung dieser Daten können helfen, potenzielle Angriffe wie Injection-Angriffe oder Cross-Site-Scripting abzuwehren und die Sicherheit der Webseite zu stärken.

HTTP REQUEST variable

Diese Option führt eine Datenbereinigung durch, um schädlichen Code oder potenziell gefährliche Eingaben zu entfernen. Das Problem dabei ist, dass eine zu strenge Bereinigung auch legitime Daten verändern oder entfernen könnte, was sich auf die Funktionalität der Webseite auswirken kann.

  • Sanitise REQUEST variable kann die "Sanitize"-Funktion für legitime Eingaben zu restriktiv sein und dazu führen, dass bestimmte Formulare oder Funktionen nicht mehr wie erwartet funktionieren.

Es wird empfohlen, diese Option mit Vorsicht zu aktivieren und vorherige Sicherungskopien deiner Webseite zu erstellen. Außerdem ist es ratsam, die Webseite nach der Aktivierung dieser Option gründlich zu überprüfen, um sicherzustellen, dass keine wesentlichen Funktionen beeinträchtigt wurden und dass die Webseite weiterhin wie erwartet funktioniert. Bei Unsicherheit oder nicht genauem verständnis, wie diese Funktion die Webseite beeinflussen könnte, ist es möglicherweise besser, diese Option zunächst nicht zu aktivieren oder Hilfe von Experten in Anspruch zu nehmen.

Cookies

"Scan Cookies" und "Sanitize Cookies" sind Sicherheitsfunktionen, die sich auf die Überwachung und Bereinigung von Cookies beziehen, die von der Webseite gesetzt oder empfangen werden.

  1. Scan Cookies: Diese Funktion überwacht die Cookies, die von der Webseite gesetzt oder empfangen werden. Cookies sind kleine Datenstücke, die von Webseiten im Browser des Benutzers gespeichert werden. Das Plug-in scannt diese Cookies auf potenzielle Anzeichen von Angriffen oder schädlichem Inhalt. Dies ermöglicht die Erkennung verdächtiger oder möglicherweise gefährlicher Cookies, die möglicherweise Sicherheitsrisiken darstellen könnten.
  2. Sanitize Cookies: Ähnlich wie bei der "Sanitize Variable"-Funktion für GET- und POST-Variablen reinigt diese Funktion Cookies, um sicherzustellen, dass sie frei von schädlichem Code oder potenziell gefährlichen Inhalten sind. Sie filtert und bereinigt die Cookies, bevor sie auf dem Browser des Benutzers gespeichert werden. Dies hilft, potenzielle Sicherheitslücken zu minimieren und schädliche oder manipulierte Cookies zu neutralisieren.

Diese Funktionen sind wichtig, um die Sicherheit der Webseite zu erhöhen, insbesondere wenn Cookies von Drittanbietern oder anderen Quellen stammen können. Die Überwachung und Bereinigung von Cookies können dabei helfen, mögliche Angriffsvektoren wie Cross-Site-Scripting (XSS) oder böswillige Cookie-Manipulation zu verhindern.

Es ist jedoch wichtig zu beachten, dass das Aktivieren dieser Funktionen die Funktionalität bestimmter Cookies beeinträchtigen oder dazu führen kann, dass legitime Cookies fälschlicherweise als verdächtig markiert und entfernt werden. Dies kann sich auf die Funktionalität und Benutzererfahrung der Webseite auswirken. Es ist daher ratsam, die Auswirkungen dieser Funktionen zu überwachen, nachdem sie aktiviert wurden, und sicherzustellen, dass keine wichtigen Funktionen beeinträchtigt wurden.

HTTP_USER_AGENT server variable

Die Servervariable HTTP_USER_AGENT enthält Informationen zum Benutzer-Agenten, der den aktuellen HTTP-Request an den Server sendet. Diese Informationen enthalten normalerweise Details zum verwendeten Browser, Betriebssystem und möglicherweise anderen relevanten Details, die vom Client gesendet werden.

  1. Scan HTTP_USER_AGENT: Diese Funktion überwacht und analysiert die HTTP_USER_AGENT-Header in den HTTP-Requests, die an den Server gesendet werden. Dies ermöglicht die Überprüfung auf verdächtige oder ungewöhnliche Benutzer-Agenten, die möglicherweise auf Bots, Scanner oder andere böswillige Software hinweisen.
  2. Sanitise HTTP_USER_AGENT: Ähnlich wie bei anderen "Sanitize"-Funktionen bereinigt diese Option die HTTP_USER_AGENT-Informationen. Sie filtert potenziell gefährliche oder schädliche Inhalte aus dem HTTP_USER_AGENT-Header heraus, um Sicherheitsrisiken zu minimieren.
  3. Block suspicious bots/scanners /: Diese Funktion blockiert oder sperrt verdächtige Benutzer-Agenten, die als Bots, Scanner oder potenziell schädliche Software identifiziert werden. Sie hilft dabei, den Zugriff solcher Bots oder Scanner auf die Webseite zu unterbinden, um die Sicherheit zu verbessern und mögliche Angriffsvektoren zu reduzieren.

Diese Funktionen sind wichtige Sicherheitsmaßnahmen, um verdächtige Aktivitäten, die durch abnormale oder schädliche Benutzer-Agenten verursacht werden könnten, zu überwachen, zu bereinigen und zu blockieren. Es ist jedoch wichtig zu beachten, dass einige legitime Anwendungen oder Dienste auch spezifische Benutzer-Agenten verwenden können, die möglicherweise fälschlicherweise als verdächtig eingestuft werden könnten.

Es ist ratsam, nach der Aktivierung dieser Funktionen das Verhalten der Webseite zu überwachen, um sicherzustellen, dass keine legitimen Benutzer-Agenten oder Dienste fälschlicherweise blockiert oder beeinträchtigt werden. Gegebenenfalls können Ausnahmen oder Whitelists für legitime Benutzer-Agenten eingerichtet werden, um sicherzustellen, dass diese ordnungsgemäß funktionieren können.

HTTP_REFERER server variable

Die HTTP_REFERER-Servervariable gibt Informationen darüber, von welcher URL aus der Benutzer auf die aktuelle Seite gelangt ist. Diese Variable enthält normalerweise die URL der vorherigen Webseite, von der der Benutzer einen Link oder eine Anfrage verfolgt hat.

  1. Scan HTTP_REFERER: Diese Funktion überwacht die HTTP_REFERER-Header in den HTTP-Requests, die an den Server gesendet werden. Sie ermöglicht die Überprüfung auf verdächtige oder ungewöhnliche Referer-Informationen, die möglicherweise auf bestimmte Angriffe wie CSRF (Cross-Site Request Forgery) oder andere böswillige Aktivitäten hinweisen könnten.
  2. Sanitize HTTP_REFERER: Ähnlich wie bei anderen "Sanitize"-Funktionen reinigt diese Option die HTTP_REFERER-Informationen. Sie filtert potenziell gefährliche oder schädliche Inhalte aus dem HTTP_REFERER-Header heraus, um Sicherheitsrisiken zu minimieren.

Diese Funktionen sind wichtige Sicherheitsmaßnahmen, um verdächtige Aktivitäten oder mögliche Angriffsvektoren, die durch Referer-Informationen verursacht werden könnten, zu überwachen, zu filtern und zu bereinigen. Einige Sicherheitsbedrohungen wie CSRF-Angriffe können Informationen im HTTP_REFERER-Header ausnutzen, um böswillige Aktionen auszuführen.

Es ist jedoch wichtig zu beachten, dass einige legitime Anwendungen oder Dienste möglicherweise Referer-Informationen verwenden, die möglicherweise fälschlicherweise als verdächtig eingestuft werden könnten. Daher sollte nach der Aktivierung dieser Funktionen das Verhalten der Webseite überwacht werden, um sicherzustellen, dass keine legitimen Referer blockiert oder beeinträchtigt werden. Gegebenenfalls können Ausnahmen oder Whitelists für legitime Referer eingerichtet werden, um sicherzustellen, dass diese ordnungsgemäß funktionieren können.

  1. Block POST requests that do not have an HTTP_REFERER header: Die HTTP_REFERER-Header-Variable wird normalerweise von einem Browser gesendet und gibt die URL der Seite an, von der aus die aktuelle Anfrage stammt. Einige Anwendungen und Skripte verwenden diesen Header, um die Herkunft von Anfragen zu überprüfen und deren Legitimität zu bestätigen.
    • Die Option "Block POST requests that do not have an HTTP_REFERER header" blockiert POST-Anfragen, die keinen HTTP_REFERER-Header enthalten. Das bedeutet, dass Anfragen, die von einer Seite ohne diesen Header gesendet werden, blockiert werden. Dies kann bestimmte Arten von Anfragen einschränken, die keine oder eine leere HTTP_REFERER-Header-Variable enthalten.

Es wird empfohlen, diese Option deaktiviert zu lassen, wenn Skripte oder Anwendungen sind, die keine HTTP_REFERER-Header-Variable in ihren Anfragen senden. Einige bekannte Dienste wie PayPal IPN (Instant Payment Notification) oder WordPress WP-Cron könnten solche Anfragen senden. Wenn diese Option aktiviert ist, könnten legitime Anfragen dieser Dienste blockiert werden, was zu Funktionsstörungen oder Problemen führen könnte.

IP

Diese Sicherheitsmaßnahmen beziehen sich auf die Überwachung und Blockierung von HTTP-Anfragen und Datenverkehr, die bestimmte IP-bezogene Sicherheitsrisiken darstellen könnten:

  1. Block localhost IP in GET/POST request / Lokale Host-IP in GET/POST-Anfrage blockieren: Diese Funktion blockiert HTTP-Anfragen, bei denen die lokale Host-IP-Adresse in den GET- oder POST-Anfragen enthalten ist. Dies dient dazu, Anfragen abzufangen, die von der eigenen Server-IP stammen oder darauf zielen, was oft auf potenziell schädliche oder nicht autorisierte Anfragen hinweisen könnte.
  2. Block HTTP requests with an IP in the HTTP_HOST header / Blockieren von HTTP-Anfragen mit einer IP im HTTP_HOST-Header: Der HTTP_HOST-Header gibt normalerweise den Hostnamen oder die IP-Adresse der angeforderten Ressource an. Das Blockieren von Anfragen mit einer IP-Adresse im HTTP_HOST-Header könnte darauf abzielen, Anfragen zu blockieren, die möglicherweise auf spezifische Sicherheitsprobleme oder Angriffsvektoren hinweisen.
  3. Scan traffic coming from localhost and private IP address spaces / Scannen des Datenverkehrs von lokalen Host- und privaten IP-Adressräumen: Diese Funktion überwacht und analysiert den Datenverkehr, der von lokalen Hosts oder aus privaten IP-Adressbereichen stammt. Lokale Hosts sind normalerweise der eigene Server oder interne Netzwerke. Das Scannen dieses Datenverkehrs kann dazu beitragen, potenziell schädliche oder nicht autorisierte Aktivitäten innerhalb des lokalen Netzwerks zu erkennen und zu blockieren.

Diese Sicherheitsfunktionen zielen darauf ab, bestimmte IP-bezogene Sicherheitsrisiken zu minimieren, indem potenziell verdächtige Anfragen oder Datenverkehr, die auf spezifische Muster oder Bedingungen hinweisen, erkannt und blockiert werden. Sie sind wichtige Maßnahmen, um die Sicherheit des Servers und der Webanwendung zu erhöhen.

Es ist jedoch wichtig zu beachten, dass solche Maßnahmen gelegentlich legitime Anfragen oder Datenverkehr blockieren könnten, insbesondere wenn bestimmte Konfigurationen oder spezifische Netzwerkkonfigurationen vorhanden sind. Daher ist eine sorgfältige Überwachung und gegebenenfalls das Hinzufügen von Ausnahmen oder Whitelists für legitime IP-Adressen erforderlich, um sicherzustellen, dass wichtige Funktionalitäten nicht beeinträchtigt werden.

Tab 3: Advanced Policies

Advanced Policies

Advanced Policies – Erweiterte Richtlinien

In diesem Teil werden die erweiterten Richtlinien behandelt. Vorsicht ist zu walten, wenn Änderungen vorgenommen werden, da dies mehr schaden als nützen könnte . Wenn Sie sich nicht sicher sind, belassen Sie die Standardwerte.

Somit ist das Folgende nur als Überblick zu betrachten und sich der jeweilign Links erweiterten Information zu bedienen!

HTTP response headers – HTTP-Antwortheader
  • Set X-Content-Type-Options to protect against MIME type confusion attacks geht es darum, eine Sicherheitsmaßnahme zu aktivieren, die vor Angriffen durch MIME-Typ-Verwirrung schützt. Diese Einstellung hilft dabei, die Sicherheit der Webseite zu erhöhen, indem sie sicherstellt, dass der Browser den vom Server bereitgestellten MIME-Typ nicht ändert. Es ist eine präventive Maßnahme, um mögliche Angriffe zu minimieren, indem die Verwirrung der MIME-Typen verhindert wird. Der detailliertere Kontext zu dieser Einstellung ist über die verlinkten Erklärungen zugänglich.
  • Set X-Frame-Options to protect against clickjacking attempts ist eine Sicherheitseinstellung, die deine Webseite vor Clickjacking-Versuchen schützt. Clickjacking ist eine Art von Angriff, bei dem ein schädlicher Akteur Inhalte einer Webseite in einem unsichtbaren Rahmen versteckt, um den Benutzer dazu zu bringen, ungewollte Aktionen auszuführen, indem er auf scheinbar harmlose Elemente klickt. Durch das Aktivieren der X-Frame-Options kannst du verhindern, dass deine Webseite in Frames oder iframes auf anderen Domains eingebettet wird, was potenzielle Clickjacking-Angriffe abschwächt. Es ist eine wichtige Sicherheitsmaßnahme, um die Integrität deiner Webseite zu schützen.
    • Wenn diese Option auf DENY gesetzt wird, können einige Funktionen des Blogs, seiner Themes oder Plugins beeinträchtigt werden.
    • Der detailliertere Kontext zu dieser Einstellung ist über die verlinkten Erklärungen zugänglich.
  • Set X-XSS-Protection: Der X-XSS-Protection-Header war früher ein gängiger Schutzmechanismus gegen XSS-Angriffe. Allerdings haben die meisten modernen Browser die Unterstützung für diesen Header eingestellt, da er als ineffektiv angesehen wird. Die Verwendung der Content-Security-Policy (CSP) gilt heute als empfohlene Methode gilt, um XSS-Angriffe zu verhindern. CSP bietet umfassendere Möglichkeiten zur Steuerung und Absicherung der Webseite gegen XSS-Angriffe im Vergleich zum veralteten X-XSS-Protection-Header.
    • Der detailliertere Kontext zu dieser Einstellung ist über die verlinkten Erklärungen zugänglich.
  • Force SameSite flag on all cookies to mitigate CSRF attacks. Das Setzen des "SameSite"-Flags auf alle Cookies ist eine Maßnahme zur Minimierung von CSRF (Cross-Site Request Forgery) Angriffen. Dieses Flag wird verwendet, um festzulegen, wie Cookies in Browsern zwischen verschiedenen Seiten und Domains geteilt werden. Wenn das "SameSite"-Flag auf "Strict" oder "Lax" gesetzt ist, werden Cookies nur für Anfragen gesendet, die von derselben Ursprungswebsite stammen, was die Wahrscheinlichkeit von böswilligen Anfragen von anderen Seiten aus verringert. Dies trägt dazu bei, die Sicherheit der Webseite gegenüber CSRF-Angriffen zu erhöhen.
    • Der detailliertere Kontext zu dieser Einstellung ist über die verlinkten Erklärungen zugänglich.
  • Force HttpOnly flag on all cookies to mitigate XSS attacks: Das Setzen des "HttpOnly"-Flags auf Cookies ist eine Sicherheitsmaßnahme, die bei der Abwehr von XSS (Cross-Site Scripting) Angriffen hilft. Indem das "HttpOnly"-Flag aktiviert wird, wird verhindert, dass JavaScript über das Document Object Model (DOM) auf Cookies zugreift. Dies reduziert das Risiko, dass Angreifer Cookies stehlen und so sensible Daten wie Session-IDs erhalten können.
    • Wenn PHP-Skripte Cookies verwendet werden, auf die über JavaScript zugegriffen werden muss, sollte diese Option nicht aktiviert sein.
    • Der detailliertere Kontext zu dieser Einstellung ist über die verlinkten Erklärungen zugänglich.
  • Set Strict-Transport-Security (HSTS) to enforce secure connections to the server: Die "Strict-Transport-Security" (HSTS) Richtlinie ist eine Sicherheitsmaßnahme, die sicherstellt, dass eine Website nur über eine verschlüsselte Verbindung (HTTPS) aufgerufen wird. Indem HSTS aktiviert wird, wird Browsern mitgeteilt, dass sie immer eine verschlüsselte Verbindung verwenden sollen, wenn sie auf diese Website zugreifen. Dies hilft, Man-in-the-Middle-Angriffe zu verhindern und die Sicherheit der Verbindung zwischen Browser und Server zu erhöhen.
    • Der detailliertere Kontext zu dieser Einstellung ist über die verlinkten Erklärungen zugänglich.
  • Set Content-Security-Policy for the website frontend legt fest, welche Ressourcen auf einer Website geladen werden dürfen. Es ist eine Sicherheitsmaßnahme, die das Risiko von Cross-Site-Scripting-Angriffen (XSS) verringert, indem sie steuert, welche Ressourcen (wie Skripte, Stylesheets, Bilder usw.) von einer Website geladen werden können. Indem bestimmte Sicherheitsrichtlinien definiert werden, kann die CSP das Risiko von böswilligen Skripten reduzieren, die von anderen Domains oder Quellen auf einer Seite ausgeführt werden können.
    • Der detailliertere Kontext zu dieser Einstellung ist über die verlinkten Erklärungen zugänglich.
  • Set Content-Security-Policy for the WordPress admin dashboard: Die Content-Security-Policy (CSP) kann auch für das WordPress-Admin-Dashboard konfiguriert werden, um die Sicherheit zu verbessern. Sie legt fest, welche Ressourcen und Inhalte auf der Admin-Oberfläche geladen werden dürfen. Indem sie bestimmte Richtlinien für Skripte, Stylesheets, Bilder und andere Ressourcen definiert, kann die CSP das Risiko von Cross-Site-Scripting-Angriffen verringern und die Sicherheit des Admin-Bereichs verbessern.
    • Der detailliertere Kontext zu dieser Einstellung ist über die verlinkten Erklärungen zugänglich.
  • Set Referrer-Policy (Chrome, Opera and Firefox browsers): Die Referrer-Policy-Header setzen Richtlinien für den Referrer, der von einem Browser gesendet wird, wenn ein Benutzer auf eine Seite zugreift. Es legt fest, wie viele Informationen über die ursprüngliche Seite an die aufgerufene Seite weitergegeben werden. Diese Einstellung hilft, die Privatsphäre der Benutzer zu schützen und bestimmte Informationen zu limitieren oder zu verbergen, die an andere Seiten weitergegeben werden könnten.
    • Der detailliertere Kontext zu dieser Einstellung ist über die verlinkten Erklärungen zugänglich.
PHP
    • Block PHP built-in wrappers in GETPOSTHTTP_USER_AGENTHTTP_REFERER and cookies: Das Blockieren der PHP-Built-in-Wrappers in verschiedenen HTTP-Bereichen wie GET, POST, HTTP_USER_AGENT, HTTP_REFERER und Cookies ist eine Sicherheitsmaßnahme. PHP-Built-in-Wrappers sind Mechanismen, die PHP-Skripte verwenden, um auf verschiedene Ressourcen zuzugreifen, und das Blockieren dieser kann dazu beitragen, potenzielle Sicherheitslücken zu schließen, indem der direkte Zugriff auf bestimmte Ressourcen durch bestimmte HTTP-Bereiche eingeschränkt wird.
    • Block serialized PHP objects in the following global variables: Das Blockieren von serialisierten PHP-Objekten in globalen Variablen ist eine Sicherheitsmaßnahme, die darauf abzielt, unerwünschte oder potenziell gefährliche Daten zu verhindern, die über globale Variablen übertragen werden könnten. Serialisierte PHP-Objekte könnten möglicherweise Schadcode oder unerwünschte Informationen enthalten. Durch das Blockieren in den globalen Variablen wird verhindert, dass diese Daten im System verarbeitet oder ausgeführt werden.
    • Block attempts to override PHP Superglobals: Das Blockieren von Versuchen, PHP-Superglobals zu überschreiben, ist eine Sicherheitsmaßnahme, um unerwünschte Änderungen oder Manipulationen an den sogenannten Superglobalen zu verhindern. Diese Superglobalen, wie z. B. $_GET, $_POST, $_SESSION usw., sind wichtige Arrays in PHP, die wichtige Informationen speichern und von verschiedenen Teilen der Anwendung verwendet werden. Wenn sie manipuliert werden, könnte dies zu Sicherheitslücken oder unerwünschtem Verhalten der Anwendung führen. Das Blockieren von Versuchen, diese Superglobalen zu überschreiben, schützt vor solchen potenziellen Bedrohungen.
    • Hide PHP notice and error messages: Das Ausblenden von PHP-Hinweisen und Fehlermeldungen ist eine gängige Sicherheitspraxis, die verhindert, dass sensible Informationen oder potenziell anfällige Details für Angreifer angezeigt werden. Solche Meldungen könnten Informationen über die Anwendungsstruktur oder Schwachstellen preisgeben, die für böswillige Zwecke ausgenutzt werden könnten. Indem man die Anzeige dieser Meldungen deaktiviert, trägt man zur Sicherheit der Anwendung bei und reduziert das Risiko von Angriffen.
    • Sanitise PHP_SELF: Dieser Prozess entfernt potenziell gefährliche Zeichen oder Muster aus dem Wert von PHP_SELF, der den Namen des PHP-Skripts enthält, das gerade ausgeführt wird. Das Ziel ist es, böswillige Eingaben zu bereinigen, die möglicherweise zu Schwachstellen wie Injection-Angriffen führen könnten.
    • Sanitise PATH_TRANSLATED: Diese Funktion säubert den Wert von PATH_TRANSLATED, der den physischen Pfad zur angeforderten Datei darstellt. Das Entfernen unerwünschter oder potenziell gefährlicher Elemente trägt dazu bei, dass nur zulässige Pfade verwendet werden, um mögliche Sicherheitslücken zu minimieren.
    • Sanitise PATH_INFO: Ähnlich wie bei PATH_TRANSLATED reinigt diese Funktion den Wert von PATH_INFO, der zusätzliche Pfadinformationen enthält, die möglicherweise durch Benutzereingaben beeinflusst werden. Die Bereinigung verhindert, dass unerlaubte Zeichen oder Muster zu potenziellen Sicherheitslücken führen.
Various – Verschiedenes
  • Block the DOCUMENT_ROOT server variable in HTTP request: Diese Einstellung verhindert, dass die DOCUMENT_ROOT-Servervariable in HTTP-Anfragen verfügbar ist. DOCUMENT_ROOT enthält den physischen Pfad zum Root-Verzeichnis des Servers. Durch das Blockieren wird möglichen Angriffen entgegengewirkt, die auf Informationen über die Serverkonfiguration abzielen könnten.
    • Das Blockieren der DOCUMENT_ROOT-Servervariable in HTTP-Anfragen ist eine Sicherheitsmaßnahme, die verhindern soll, dass diese spezifische Serverinformation preisgegeben wird. Die DOCUMENT_ROOT-Variable gibt den Pfad zum Root-Verzeichnis der Webseite auf dem Server an. Indem diese Information blockiert wird, wird potenziell die Exposition sensibler Serverdetails verringert, was ein Sicherheitsrisiko minimieren kann,
    • Es ist wichtig zu beachten, dass das Blockieren dieser Variable Auswirkungen auf bestimmte Funktionen oder Anwendungen haben kann, die möglicherweise auf diese Information angewiesen sind. Manche Skripte oder Anwendungen könnten darauf basieren oder sie benötigen, um korrekt zu funktionieren. Bevor du diese Einstellung aktivierst, solltest du sicherstellen, dass sie keine negativen Auswirkungen auf die Funktionalität deiner Webseite oder Anwendungen hat. Es könnte ratsam sein, vor der Aktivierung dieser Sicherheitseinstellung eine gründliche Überprüfung durchzuführen und sicherzustellen, dass alle benötigten Funktionen weiterhin ordnungsgemäß arbeiten.
  • Block ASCII character 0x00 (NULL byte): Die Blockierung von ASCII-Steuerzeichen wie dem NULL-Byte (0x00) ist wichtig, um sogenannte Null-Byte-Injections zu verhindern. Diese Angriffe versuchen, Sicherheitsvorkehrungen zu umgehen, indem sie NULL-Bytes verwenden, um Daten zu manipulieren oder unerwünschte Aktionen auszuführen.
  • Block ASCII control characters 1 to 8 and 14 to 31: ASCII-Steuerzeichen von 1 bis 8 und von 14 bis 31 sind nicht-druckbare Zeichen, die potenzielle Sicherheitslücken darstellen könnten. Indem diese blockiert werden, wird das Risiko von Angriffen, die auf diese Zeichen abzielen, minimiert. Die Einstellung, die ASCII-Steuerzeichen von 1 bis 8 und 14 bis 31 zu blockieren, ist eine Sicherheitsmaßnahme, die verhindern soll, dass bestimmte ASCII-Steuerzeichen in HTTP-Anfragen verarbeitet werden. Diese Zeichen können potenziell zu Sicherheitsproblemen führen, insbesondere bei der Verarbeitung von Daten, da sie in einigen Kontexten für Angriffe ausgenutzt werden können.
    • Wenn diese Einstellung aktiviert ist, blockiert das bestimmte ASCII-Steuerzeichen in den angegebenen Bereichen. Es ist jedoch wichtig zu beachten, dass dies auch Auswirkungen auf die Datenverarbeitung haben kann. Einige Anwendungen oder Funktionen könnten möglicherweise auf diese Zeichen angewiesen sein und ihre Blockierung könnte die Funktionalität beeinträchtigen.
    • Vor der Aktivierung dieser Sicherheitsmaßnahme sollte sicherstellt werden, dass sie keine negativen Auswirkungen auf die Funktionalität der Webseite oder Anwendungen hat. Es ist ratsam, vor der Aktivierung eine umfassende Überprüfung durchzuführen, um sicherzustellen, dass alle erforderlichen Funktionen weiterhin ordnungsgemäß funktionieren. Wenn keine Anwendungen von diesen ASCII-Steuerzeichen abhängig sind, kann die Aktivierung dieser Einstellung dabei helfen, potenzielle Sicherheitslücken zu schließen.

↑ Firewall Policies / 3 Tabs

Monitoring

Anti-Malware

  • Seit Version 3.6 wurde die Anti-Malware-Funktion durch ein brandneues Plugin ersetzt: NinjaScanner.

Network bei Multisites

  • Der Menüpunkt "Network" ist nur in WordPress Multisites: Das NinjaFirewall-Statussymbol in der WordPress-Symbolleiste aller Websites im Netzwerk an NinjaFirewall Status anzeigen oder nicht anzeigen.

Event Notifications

Einstellungen zu:

  • WordPress admin dashboard
  • Plugins
  • Themes
  • Core
  • Security updates
  • Administrator account
  • Daily report
  • Log
  • PHP backtrace
  • Contact email

Weiter siehe Event Notifications.

Login Protection

NinjaFirewall bietet zwei Möglichkeiten der HTTP-Authentifizierung für die WordPress Login Protection an.

  • Always ON, das bedeutet, es wird generell vor der wp-login.php Seite ein weiteres Login im Stil von WordPress geschaltet.
  • Yes, if under attack, wenn die Login Seite angegriffen wird, wird die HTTP-Authentifizierung automatisch davor geschaltet.

Original Hilfetext von NinjaFirewall: NinjaFirewall verarbeitet eingehende HTTP-Anfragen vor Ihrem Blog und seinen Plug-ins und ist damit das einzige Plug-in für WordPress, das in der Lage ist, es vor sehr großen Brute-Force-Angriffen zu schützen, einschließlich verteilter Angriffe von mehreren tausend verschiedenen IPs.

Eine „brute force” Attacke – siehe dazu auch Brute-Force-Methodewikipedia – ist der Versuch, durch automatisierte, tausendfache Eingabe von Benutzername und Passwort das Log-in eines Benutzers festzustellen. WordPress hat standardmäßig kei­nen Schutz, um dies zu verhindern.

Sie bemerken also überhaupt nicht, dass jemand versucht, in Ihre WordPress-Website einzubrechen.

Logs

Relevante Einschränkung der Login Protection: Die Login Protection von ähnlichen WordPress Plug-ins ba­sie­ren darauf, dass immer dieselbe IP-Adresse für die „brute force“ Attacke benutzt wird. Je professioneller die Attacke ist, umso eher wird die IP-Adresse bei jedem Zugriff gewechselt. Ein möglichst täg­licher Blick in das Log ist hilfreich.

"Log Options": Auto delete log beachten.

Security Rules

  • Rules Updates
  • Rules Editor

Siehe Security Rules > Rules Update.

Statistik von Hackversuchen, bspw.

MonatCriticalHighMediumGesamt
2020-0130165 82277
2020-0224198141
2020-03296458151
2020-04011112
2020-051796099338
2020-0629461157

Einarbeitung brauch es zum Know-how.


Der Artikel um Ninja Firewall ist auch einer Vorlage von WaybackMachine, welche Website so nicht mehr im Internet ist und erweitert meinen eigenen Beitrag zum Thema WordPress absichern. Ich möchte mich bei Autor Frank für die Vorlage bedanken!


Diverse Überlegungen zur Website-Sicherheit

Im Zusammenhang damit ergeben sich einige Fragen, zum Beispiel zur 7G-Firewall und dem Plug-in "Blackhole for Bad Bots". Außerdem eine Gegenüberstellung von "Blackhole for Bad Bots" und der "7G-Firewall".

Die Sicherheit Ihrer Website ist von entscheidender Bedeutung, und es ist wichtig, verschiedene Aspekte der Sicherheit zu berücksichtigen. Neben der Implementierung von Firewalls und Bot-Schutzplugins ist auch die Aktivierung der Zwei-Faktor-Authentifizierung (2FA) eine effektive Maßnahme, um Ihre Website vor unbefugtem Zugriff zu schützen.

  • Die 7G-Firewall bietet in der .htaccess-Datei des Servers zusätzliche Schutzregeln, um potenziell schädliche Anfragen bereits auf Serverebene zu blockieren, bevor sie WordPress erreichen.
  • NinjaFirewall und 'Blackhole for Bad Bots' haben unterschiedliche Schwerpunkte. NinjaFirewall agiert auf der Ebene des PHP-Interpreters in WordPress und bietet allgemeine Sicherheitsmaßnahmen, während 'Blackhole for Bad Bots' spezifisch darauf ausgerichtet ist, bekannte unerwünschte Bots zu blockieren und umzuleiten.
  • Die Zwei-Faktor-Authentifizierung (2FA) ist eine äußerst wirksame Methode zur Steigerung der Sicherheit Ihrer Website. Sie stellt sicher, dass der Zugriff auf das Benutzerkonto nicht nur durch das Kenntnisnahme eines Passworts erfolgt, sondern auch durch eine zusätzliche Bestätigungsmethode. Dadurch wird das Risiko von unbefugtem Zugriff, Datenverlust und Identitätsdiebstahl erheblich reduziert.

Die Kombination mehrerer Sicherheitslösungen kann eine umfassende Sicherheitsstrategie bieten, aber auch Performance-Probleme verursachen. Daher ist eine sorgfältige Evaluierung wichtig, um Konflikte und redundante Funktionen zu vermeiden.

NinjaFirewall + 7G-Firewall

Ein sicherer und effektiver Schutz vor Cyberbedrohungen ist entscheidend für die Integrität und Leistung einer Website. Die Überlegung, in welchem Verhältnis NinjaFirewall und die 7G-Firewall stehen, ergibt sich beispielsweise aus der folgenden Supportfrage 7G-Firewall: Ist es möglich, die 7G-Firewall zu meinem .htaccess hinzuzufügen, oder sind diese Funktionen bereits in NinjaFirewall integriert? Oder führt dies zu Fehlern, wenn ich beide gleichzeitig verwende?

NinjaFirewall und die 7G-Firewall arbeiten auf unterschiedlichen Ebenen der Webserver-Sicherheit. Die 7G-Firewall wird in der Regel in der .htaccess-Datei des Servers implementiert und arbeitet auf Ebene des HTTP-Servers, während NinjaFirewall auf der Ebene des PHP-Interpreters innerhalb von WordPress agiert.

Der HTTP-Server, der die Anfragen verarbeitet, reagiert auf die Regeln in der .htaccess-Datei, während der PHP-Interpreter innerhalb von WordPress aktiv ist, um die PHP-Codeausführung und -verarbeitung zu ermöglichen.

Die beiden Firewalls ergänzen sich normalerweise, da sie unterschiedliche Aspekte der Sicherheit abdecken und auf verschiedenen Ebenen des Webserver-Stacks arbeiten. Das bedeutet, dass sie sich normalerweise nicht gegenseitig behindern oder stören sollten.


Zur Frage Share Webhosting und 7G-Firewall sehe zum Beitrag ".htaccess Datei!" den Abschnitt Share Webhosting und 7G-Firewall.

NinjaFirewall und Blackhole for Bad Bots

Das Plug-in NinjaFirewall und Blackhole for Bad Bots haben unterschiedliche Funktionen. Während NinjaFirewall sich auf die Sicherheit der Website konzentriert und verschiedene Schutzmaßnahmen bietet, ist 'Blackhole for Bad Bots' spezifischer auf die Blockierung von bekannten unerwünschten Bots und Spammer ausgerichtet.

Indem 'Blackhole for Bad Bots' eine Falle (einen sogenannten Blackhole) für diese unerwünschten Besucher erstellt und somit werden diese Bots unwissentlich auf eine Seite geleitet, die für normale Besucher unsichtbar ist. Es ist eine Art "Honigtopf", um verdächtigen Traffic zu erkennen und zu blockieren.

'Blackhole for Bad Bots' und die Blockierung von Bots:

  • 'Blackhole for Bad Bots' konzentriert sich speziell darauf, bekannte unerwünschte Bots zu identifizieren und zu blockieren. Dies geschieht auf einer höheren Ebene, auf der Ebene der HTTP-Anfragen. Das Plugin erkennt, wenn ein Bot versucht, auf die Website zuzugreifen, und blockiert oder leitet ihn um, um die Website vor unerwünschtem Crawlen und potenziell schädlichen Aktivitäten zu schützen.

Es kann sinnvoll sein, beide Tools zu nutzen, um eine umfassende Sicherheitsstrategie zu implementieren. Jedoch ist es auch wichtig zu beachten, dass zu viele Sicherheits-Plug-ins möglicherweise die Performance der Website beeinträchtigen können.

Blackhole for Bad Bots und 7G-Firewall

'Blackhole for Bad Bots' und '7G-Firewall' sind unterschiedliche Ansätze zur Sicherung der Website.

Die 7G-Firewall ist eine Reihe von Regeln, die in der .htaccess-Datei auf dem Server platziert werden. Sie besteht aus einer Liste von Regeln, die potenziell schädliche HTTP-Anfragen blockieren sollen, noch bevor sie WordPress erreichen. Diese Regeln helfen dabei, viele bekannte Angriffsvektoren und Schwachstellen zu blockieren, bevor sie die WordPress-Instanz erreichen.

Beide bieten einen gewissen Schutz vor unerwünschtem Traffic und Angriffen, jedoch auf unterschiedliche Weise und auf verschiedenen Ebenen des Server-Stacks. Einige Benutzer kombinieren möglicherweise verschiedene Sicherheitslösungen, um eine umfassendere Abdeckung zu erreichen.

Zwei-Faktor-Authentifizierung (2FA)

In NinjaFirewall gibt es keine 2FA. Zu diesem Zweck empfielt der Autor von Ninja Firewall ninetechnet das Plug-in: Two-Factor. Siehe Supportanfrage 2FA with Ninja.

Wie ist das? – die Antworten sind im Beitrag WP Security! – Zwei-Faktor-Authentifizierung (2FA)

Rechtssicherheit und Security

Rechtssicherheit und Sicherheitshinweis: Das hier ist keine Rechtsberatung, nur ein freundlicher Reminder! 🙂

Der Beitrag wurde mit fachlicher Unterstützung erstellt.


Aktualisiert im Jahr 2024 April