Leitfaden

Kostenloses IP-Schutz-Plugin für WordPress: Installation und Einstellungen

Tore für Anmeldung, Kommentare, Registrierung und REST, Installation in fünf Schritten, Monitor-Modus, zwei Schwellen, gebrandete Bildschirme, Cache- und Cloudflare-Hinweise.

IP-DB-Team 6 Min. Lesezeit 3× gelesen 0 Kommentare
WordPress

Fast alle Angriffe auf WordPress-Seiten kommen an dieselben drei Türen: Passwortversuche an wp-login.php, Spam im Kommentarformular und Scans auf Dateien wie /.env oder /.git/config, die kein Leser je anfragt. Nichts davon ist raffiniert — es funktioniert nur, weil ihnen keine Liste begegnet.

Das Plugin IP-DB Threat Protection stellt diese Liste vor Ihre Seite. Kostenlos, GPL, ab WordPress 5.8 und PHP 7.4; die meisten Entscheidungen fallen anhand einer lokalen Tabelle in Ihrer eigenen Datenbank, der Besucher wartet also auf nichts.

Was es schützt

  • Das Anmeldeformular — gelistete Adressen sehen die Login-Seite nicht; Fehlversuche werden pro Adresse gezählt.
  • Kommentare und Pingbacks — ein Kommentar von einer gelisteten Adresse wird markiert, zurückgehalten oder abgewiesen.
  • Registrierung, WooCommerce-Checkout, unauthentifizierte REST-Aufrufe und XML-RPC — jeweils ein eigener Schalter.
  • Fallen-Pfade und eine Anfragen-Obergrenze pro Minute — kosten keine Abfrage und erfordern kein Urteil: Wer /.env anfragt, ist kein Leser.
  • Wenn Sie sicher sind, jeden anonymen Seitenaufruf.

Installation in fünf Schritten

  1. Plugin von der Integrationsseite laden.
  2. In WordPress über Plugins → Installieren → Plugin hochladen das Zip einspielen, installieren, aktivieren.
  3. Im Dashboard einen kostenlosen API-Schlüssel anlegen und unter IP-DB → Einstellungen eintragen.
  4. Im IP-DB-Dashboard Blockliste jetzt synchronisieren drücken. Danach hält WP-Cron sie frisch.
  5. Einen Tag im Monitor-Modus lassen, das Aktivitätsprotokoll lesen, dann aufs Blocken umstellen.

Updates kommen von ip-db.com und erscheinen auf der Plugin-Seite wie jedes andere Update.

Der erste Tag: Monitor-Modus

Der Monitor-Modus protokolliert jede Entscheidung und blockt nichts. Sein Zweck ist, das Raten abzuschaffen: Nach einem Tag sehen Sie im Protokoll, wie viele Anfragen geblockt worden wären, welche in den Prüfbildschirm gefallen wären, und ob das wirklich Angriffe waren oder Ihr eigener Monitoring-Dienst. Seit 1.1 schaltet sich bei einem Update nichts von selbst ein: Frontend-Tor, Bildschirme und Fallen bleiben, wo Ihre Einstellungen sie gelassen haben.

Zwei Schwellen: prüfen und blocken

Das Plugin trifft keine einzige „gut oder böse"-Entscheidung. Adressen zwischen Prüf-Score und Block-Score werden nicht abgewiesen, sondern an der Sekunden-Prüfung gehalten. Dieser Mittelbereich ist der Platz für geteilte Mobilfunknetze, wiederverwendete Adressen und Firmen-NAT: nicht vertraut, aber auch nicht verurteilt. Über dem Block-Score steht die gebrandete 403-Seite.

Dazu kommt ein eigenes Tagesbudget für Abfragen dieser Seite. Ist es erreicht, hört das Tor auf zu fragen und entscheidet mit dem, was es schon weiß — damit ein betriebsamer Nachmittag nicht den Rest des Tages ungeprüft lässt.

Die Bildschirme tragen Ihren Namen

Ein gelisteter Angreifer bekommt eine Ablehnungsseite, ein grenzwertiger Besucher die Sekunden-Sicherheitsprüfung: der Bildschirm der großen CDNs, aber mit dem Namen, Logo und der Akzentfarbe Ihrer Seite. IP-DB ist nur ein kleiner Credit am Fuß.

Die Prüfung dauert mit JavaScript eine Sekunde, ohne einen Klick. Wer sie besteht, erhält ein signiertes Cookie, gebunden an Adresse und User-Agent (standardmäßig zwölf Stunden) — der Bildschirm erscheint einmal, nicht auf jeder Seite, und ein kopiertes Cookie ist anderswo wertlos. Die Ablehnungsseite kann Adresse, Score und Grund zeigen, mit einem Kontaktlink zu Ihnen, damit ein zu Unrecht Abgewiesener weiß, was er zitieren soll. Verifizierte Suchmaschinen werden nie geprüft: Googlebot und die anderen kommen nur durch, wenn forward-bestätigtes Reverse DNS beweist, dass die Adresse wirklich ihnen gehört. Jeden Bildschirm können Sie auf Ihrer eigenen Seite mit Ihren eigenen Einstellungen im Dashboard vorschauen — dabei wird nichts geblockt und kein Pass ausgegeben.

Zurückmelden

Wenn Sie es erlauben, meldet das Plugin wiederholte Fehlanmeldungen, Kommentar-Spam (auch von Hand markierten), Fallen-Treffer und geblockte Anfragen. Meldungen zählen nicht gegen Ihr Abfragekontingent. Nur so bleibt der Pool nützlich: Der Angriff, den Ihre Seite abfängt, wird zur Sperre auf der Seite eines anderen. Meldungen erscheinen im öffentlichen Profil der Adresse.

Datenschutz und DSGVO

  • Abfragen senden an ip-db.com nur die IP-Adresse des Besuchers: keine Benutzernamen, E-Mail-Adressen, Kommentartexte, Cookies oder Seiten-URLs.
  • Meldungen senden, falls aktiviert, die IP-Adresse, die Art des Missbrauchs und — bei „Kontext mitsenden" — eine Zeile wie „WordPress-Login: 6 Fehlversuche in 15 Minuten auf example.com".
  • Lokal speichert das Aktivitätsprotokoll IP-Adressen standardmäßig 30 Tage; das lässt sich auf einen Tag senken oder ganz abschalten.
  • Die Sicherheitsprüfung setzt ein Cookie (ipdb_pass): ein Ablaufzeitpunkt und eine Signatur über Adresse und User-Agent. Keine Kennung, nichts, was auf andere Seiten folgt, nichts auf dem Server — nach ePrivacy ein unbedingt erforderliches Cookie.
  • Das Plugin trägt einen fertigen Absatz in den Datenschutz-Leitfaden von WordPress ein; übernehmen müssen Sie ihn selbst.

WP-CLI und Hooks

wp ipdb status # Schlüssel, Sync und Zähler wp ipdb sync # Blockliste jetzt synchronisieren wp ipdb check 1.2.3.4 wp ipdb report 1.2.3.4 wp ipdb flush # Cache leeren

Für seitenspezifische Regeln gibt es Filter: ipdb_verdict, ipdb_skip_request, ipdb_should_report, ipdb_client_ip, ipdb_block_page. In Multisite behält jede Seite eigene Einstellungen, eigene Listenkopie und eigenes Protokoll; die Deinstallation räumt im ganzen Netzwerk auf. Für Schlüssel und Sync kommen Site-Health-Checks hinzu, ein Problem zeigt sich also dort, wo Sie ohnehin nachsehen.

Shield oder Plugin?

Beide nutzen dieselben Daten, der Unterschied ist, wo sie sitzen: Das Plugin läuft in WordPress und kennt Anwendungs-Ereignisse wie Anmeldung, Kommentar und Registrierung. Shield läuft vor WordPress, am Anfang des PHP-Prozesses, und entscheidet, bevor Ihre Seite überhaupt startet. Haben Sie auch Seiten außerhalb von WordPress oder wollen Sie das Tor vor den Full-Page-Cache setzen, nehmen Sie Shield; ist alles WordPress, ist das Plugin die bessere Wahl. Beides zusammen ist möglich, aber unnötig.

Häufige Fragen

Brauche ich einen API-Schlüssel? Kostet er etwas?

Ein Schlüssel ist nötig und kostenlos. Er weist Ihr Konto für das Tageskontingent aus: 1.000 Abfragen pro Tag kostenlos, 10.000 mit bestätigter E-Mail. Die synchronisierte Blockliste ist ein eigenes Kontingent. Es gibt keine kostenpflichtige Edition; ein höheres Kontingent wird auf Anfrage kostenlos gewährt.

Bremst es meine Seite?

Das Frontend-Tor ist eine indexierte Abfrage gegen eine lokale Tabelle in Ihrer eigenen Datenbank. Live-Abfragen passieren nur bei Anmeldung, Kommentar, Registrierung und Checkout, werden stundenlang zwischengespeichert und laufen standardmäßig nach vier Sekunden ab — und ein Timeout lässt die Anfrage durch, statt sie zu blocken.

Kann es mich aussperren?

Die Adresse, von der Sie das Plugin aktiviert haben, landet auf der Erlauben-Liste, und Administratoren werden nie bewertet. Falls es doch passiert: Das Löschen der Zeile ipdb_settings in der options-Tabelle deaktiviert das Plugin, und den Plugin-Ordner per SFTP umzubenennen funktioniert ebenfalls.

Funktioniert es mit Caching-Plugin oder CDN?

Eine Seite aus dem Full-Page-Cache erreicht PHP nie, also sehen weder Frontend-Tor noch Sicherheitsprüfung diese Anfrage. Die Tore für Anmeldung, Kommentar, Registrierung und REST werden nie gecacht und laufen immer. Sollen die Bildschirme auch vor gecachten Seiten stehen, nehmen Sie Besucher ohne ipdb_pass-Cookie aus dem Cache. Hinter Cloudflare stellen Sie den Proxy-Modus auf Cloudflare, sonst bewertet das Plugin die Edge statt Ihres Besuchers.

Für Seiten außerhalb von WordPress gibt es den Shield-Leitfaden, für einen eigenen Sensor den Honeypot-Leitfaden und zur Herkunft von Kommentar-Spam den Beitrag zur VPN-/Proxy-Erkennung.

Teilen

Kommentare 0

Teile eine Frage, Erfahrung oder Korrektur — registriert oder anonym.

Noch keine Kommentare. Schreib den ersten.

Nur Text, keine Links. Kommentare erscheinen sofort und können moderiert werden. Anmelden, um registriert zu kommentieren