Imunify360 — Reaktion auf Vorfälle und falsch-positive Meldungen
Server mit cPanel/WHM + CloudLinux. Die richtige Reaktion auf „Imunify blockiert mich“ ist, zu verstehen, WAS den Block ausgelöst hat, bevor etwas deaktiviert wird. Fast nie ist die Lösung, den Schutz auszuschalten – sondern das Legitime zu whitelisten und die Ausnahme zu dokumentieren.
Sicherheitsregeln
- Host bestätigen (
hostname -f) vor dem Handeln. - Keine globalen Sicherheitsmodule deaktivieren, um den Fall eines einzelnen Kunden zu lösen. Mit der kleinstmöglichen Ausnahme lösen (IP, Datei, Benutzer).
- Malware-Bereinigung, Wiederherstellung und Deaktivieren von Schutzmaßnahmen: VORHER BESTÄTIGEN.
- Jede Ausnahme (Whitelist, deaktivierte Regel) wird mit Grund und Datum dokumentiert.
0. Agent-Status
imunify360-agent version
systemctl status imunify360 # service imunify360 status auf CL6
imunify360-agent doctor # interne Agent-Diagnose
tail -100 /var/log/imunify360/console.log
1. Vorfall analysieren (Was hat den Kunden blockiert?)
Das Detail befindet sich im Reiter Incidents der UI; das Feld Sensor gibt die Quelle an. Blockierungen durch Active Response und PAM erscheinen als OSSEC. Bevor Regeln geändert werden: identifizieren: War es WAF (ModSecurity), Brute-Force (OSSEC/PAM), Graylist oder Malware?
# Ist die IP des Kunden in einer Liste?
imunify360-agent ip-list local list --purpose white --by-ip 1.2.3.4
imunify360-agent ip-list local list --purpose black --by-ip 1.2.3.4
2. Legitime IP blockiert → Whitelist
ip-list ist der aktuell gültige Befehl; whitelist/blacklist funktionieren in vielen
Versionen weiterhin als Alias, sind aber veraltet.
# Hinzufügen/Entfernen (praktischer Weg, der noch funktioniert):
imunify360-agent whitelist ip add 1.2.3.4 --comment "IP Büro Kunde X - 2026-06"
imunify360-agent whitelist ip delete 1.2.3.4
imunify360-agent blacklist ip add 9.9.9.9 --comment "missbräuchlicher Scanner"
# Listen abfragen (aktueller Weg):
imunify360-agent ip-list local list --purpose white
3. Falsch-positiv von WAF / ModSecurity
Zuerst die auslösende Regel lokalisieren (Feld im Incident). Wenn die IP legitim ist, reicht es meist, sie zu whitelisten (Abschnitt 2). Zum Anpassen von Schwellwerten oder Regeln:
Hauptkonfiguration : /etc/sysconfig/imunify360/imunify360.config
PAM-Schwellwert (BFM) : /etc/pam_imunify/i360.ini
Kein vollständiges Regelset wegen eines Einzelfalls deaktivieren; IP whitelisten oder die kleinste Ausnahme erstellen. Jede Änderung an diesen Dateien: BESTÄTIGEN und vorher sichern.
4. Malware in einem Account
# Einen Account scannen (maildir ausschließen beschleunigt und vermeidet Rauschen):
imunify360-agent malware on-demand start --path=/home/BENUTZER --ignore-mask=/home*/*/mail
# Alle scannen:
imunify360-agent malware on-demand start --path=/home*/*/ --ignore-mask=/home*/*/mail
# Bösartige Dateien auflisten (Standardlimit 50):
imunify360-agent malware malicious list --limit 100
Bereinigung (VORHER BESTÄTIGEN): Liste der bösartigen Dateien prüfen und über die Aktion von Imunify (UI/cleanup) bereinigen oder, falls der Account stark kompromittiert ist, aus einem sauberen Backup vor der Infektion wiederherstellen. Vor der blinden Anwendung die aktuelle Syntax von cleanup auf dem Server prüfen. Nach der Bereinigung: Passwörter ändern, CMS/Plugins aktualisieren und erneut scannen.
5. Legitime Datei als bösartig markiert → Falsch-positiv
imunify360-agent submit false-positive --reason "eigenes Theme, interner Code" /home/BENUTZER/public_html/datei.php
# Umgekehrter Fall (etwas Bösartiges, das als sauber durchging):
imunify360-agent submit false-negative /vollständiger/pfad/zur/datei
Damit der Scanner eine Datei/einen Ordner dauerhaft ignoriert, wird die Scanner-Whitelist
verwendet (JSON mit path/reason/md5/recursive). Grund dokumentieren.
6. „Nach Captcha gefragt / kann nicht rein"
Meist handelt es sich um eine Graylist (die IP des Kunden wurde aufgrund verdächtigen Verhaltens auf Grau gesetzt) oder Active Response. Mit Abschnitt 1 bestätigen und, falls die IP dem Kunden gehört, whitelisten. Das unsichtbare Captcha und die OSSEC-Timeouts (Standard 600s) werden über die Konfiguration gesteuert.
Wann Schutz NICHT deaktivieren
- Bei der Frage „Ich schalte WAF aus, damit es funktioniert" → fast immer reicht IP-Whitelist oder Dateiausnahme, nicht das Modul deaktivieren.
- HardenedPHP deaktivieren oder Imunify deinstallieren kann Updates von Apache/PHP beschädigen: niemals als Support-Shortcut.
Aktionen, die den Zustand ändern (bereinigen, wiederherstellen, Konfiguration bearbeiten, Module deaktivieren) werden vorgeschlagen und nur mit explizitem OK des Operators ausgeführt.