Honeypot-Decoy Paths: Sperrung von Scannern bereits bei der ersten Abfrage
Ein WordPress-Honeypot funktioniert, weil kein echter Besucher jemals eine Anfrage an /.env.backup oder wp-config.old.php. Der „Decoy Path Block“ von ReportedIP Hive wertet den ersten Zugriff auf einen der 40 Köderpfade als Angriffsindikator aus – ohne Zählfenster, ohne Wartezeit.
In dieser Anleitung werden die Liste der Köder, die Gründe, warum der Sensor die IP-Adresse nicht lokal sperrt, sowie die Vorgehensweise zur Übertragung der Sperre auf Serverebene behandelt.
Was ist ReportedIP Hive?
ReportedIP Hive ist ein umfassendes WordPress-Sicherheits-Plugin – 16 Attack Sensors, vier 2FA-Verfahren, progressive Blockierung und opt-in-basierte Threat Intelligence in einem kostenlosen Plugin unter der GPL-2.0-Lizenz. Der „Decoy Path Block“ ist ein Sensor der Free tier-Version. Alle weiteren Funktionen finden Sie im vollständigen Funktionsumfang von ReportedIP Hive.
40 Köderwege, ein Signal
Die in Version 2.0.9 eingeführte und in Version 2.0.14 von 16 auf 40 Einträge erweiterte „Decoy“-Liste umfasst die Dateien, nach denen Angreifer nach einer fehlerhaften Konfiguration suchen:
- Die gesamte
wp-config.php.*Backup-Familie –.bak,.old,.save,.orig,.swp,.txtsowie ein nachgestelltes~. .envSicherungen —.production.bak,.local.bak,.orig— sowie Joomlasconfiguration.php.bak.- SQL-Dumps im Webroot —
dump.sql,database.sql,backup.sql,db.sql. - Apache
.htpasswd/.htaccess.bak, AWS-Anmeldedaten (.aws/credentials,.aws/config), SSH-Schlüssel (.ssh/id_rsa,.ssh/authorized_keys) sowie Dateien mit privaten Schlüsseln (id_rsa,private.key,server.key).
Erweitern Sie die Liste mit dem reportedip_hive_decoy_paths Filter. Der Matcher erkennt auch einen „Bait“-Dateinamen hinter einem Unterverzeichnis-Präfix, sodass /site-a/.env.backup bei einer Multisite-Installation in einem Unterverzeichnis wird dies auf dieselbe Weise erfasst.
Warum wird die IP-Adresse nicht lokal gesperrt?
Seit Version 2.0.11 fügt der Decoy-Sensor die Quell-IP bewusst nicht in die lokale Sperrtabelle ein. Ein einziges False Positive – ein legitimes Backup-Plugin, ein Administrator, der auf der Live-Seite Tests durchführt, oder ein alter Crawler, der eine veraltete URL abfragt – würde die Seite andernfalls stundenlang vom eigenen Datenverkehr ausschließen. Stattdessen wird jeder Treffer entsprechend der Schweregradstufe protokolliert high, an die Community-Reputationswarteschlange weitergeleitet (Ereignis decoy_pathblock_hit) weitergeleitet, und der Besucher erhält für diese eine Anfrage einen 403-Fehler. Auf der Community-Ebene werden die Reputationskosten netzwerkweit verrechnet.
Verschieben Sie den Block auf den Server, um echte Köderdateien bereitzustellen
Befindet sich eine echte „Bait“-Datei auf der Festplatte (beispielsweise eine .env.backup die beispielsweise von Composer zurückgelassen wurde), könnten Apache oder nginx diese ausliefern, bevor PHP ausgeführt wird. Hive verwaltet automatisch einen .htaccess Rewrite-Block (zwischen den # BEGIN ReportedIP Hive Decoy / # END Markern), der diese Anfragen zur index.php zur Erkennung weiterleitet, anstatt die Datei auszuliefern. nginx-Benutzer erhalten auf der Registerkarte „Einstellungen“ einen entsprechenden Codeausschnitt, einschließlich einer Variante für exakte Übereinstimmungen für ISPConfig und verwaltete Stacks, bei denen andernfalls eine location ~ /. { deny all; } Regel andernfalls Vorrang hätte. Das Plugin schreibt niemals direkt in Ihre Serverkonfiguration – es generiert lediglich den Codeausschnitt zum Einfügen.
Verwandte Anleitungen
- Die 16 Sensoren, einschließlich 404 / Scanner-Erkennung
- Progressive IP-Sperrung für die Sensoren, die tatsächlich Sperren verhängen
- Wie „Decoy-Hits“ das Reputationsnetzwerk der Community stärken
Einzelheiten zur Absicherung auf Serverebene finden Sie in der Dokumentation zum Honeypot Server. Sehen Sie sich die vollständigen Anleitungen zum ReportedIP Hive-Plugin an oder lesen Sie den Code für die Köder auf GitHub.