Imunify360 Malware Scanner: Funktionen, Updates und Grenzen

Imunify360 als mehrschichtige Hosting-Sicherheit

Imunify360 ist keine isolierte Virensuche, sondern eine Linux-Sicherheitslösung mit mehreren Schutzebenen. Der Malware Scanner untersucht Dateien auf bekannte oder verdächtige Inhalte. Firewall sowie IDS/IPS beobachten und begrenzen auffällige Netzwerkaktivitäten, während eine Web Application Firewall, kurz WAF, HTTP-Anfragen vor der Anwendung anhand von Regeln bewertet. Reputationsprüfungen liefern weitere Signale für die Einordnung von Quellen und Aktivitäten.

Diese Aufteilung ist für Hosting-Betreiber entscheidend, weil die Schichten an unterschiedlichen Stellen greifen. Ein HTTP-Angriff auf eine bekannte Schwachstelle kann an der WAF scheitern, bevor WordPress, Joomla oder Magento den Request verarbeitet. Ein schädlicher Upload wird dagegen bei der Dateiüberprüfung relevant. Wird eine PHP-Webshell ausgeführt, kann Proactive Defense verdächtiges Verhalten während der PHP-Ausführung adressieren; sie ist jedoch keine rückwirkende Analyse des gesamten Vorfalls.

Das Modell heißt Defense in Depth: Eine einzelne Lücke oder ein übersehener Fund soll nicht allein über die Sicherheit eines Kundenkontos entscheiden. Die Malware-Erkennung kann vorhandenen Schadcode sichtbar machen, aber sie verhindert nicht zwangsläufig den ursprünglichen Exploit. Ebenso kann eine WAF einen Angriff blockieren, ohne bereits abgelegte Dateien oder manipulierte Datenbankinhalte zu bereinigen.

Keine dieser Ebenen ersetzt grundlegende Betriebsaufgaben. CMS-Kern, Plugins, Themes und Erweiterungen brauchen zeitnahe Sicherheitsupdates; restriktive Dateirechte und getrennte Zugangsdaten begrenzen die Folgen eines kompromittierten Kontos. Geprüfte Backups ermöglichen die Wiederherstellung, und bei einem Fund klärt erst eine Incident-Analyse Eintrittsweg, Reichweite und mögliche Persistenz. Imunify360 liefert dafür Schutz- und Erkennungssignale, nicht den vollständigen Beweis einer bereinigten Umgebung.

Imunify360, ImunifyAV und ImunifyAV+ unterscheiden

Funktionslisten müssen dem jeweils eingesetzten Produkt zugeordnet werden. Imunify360 ist die umfassendere Server-Sicherheitslösung; ImunifyAV und ImunifyAV+ sind davon getrennte Produkte mit Malware-bezogenen Funktionen. Wer diese Namen gleichsetzt, könnte etwa eine vorhandene Scan-Funktion mit Firewall-, Echtzeit- oder PHP-Schutz verwechseln und daraus falsche Erwartungen für einen Managed- oder Reseller-Server ableiten.

Relevant ist insbesondere, dass Real-Time Scanning und Proactive Defense laut Herstellerdokumentation nicht in ImunifyAV beziehungsweise ImunifyAV+ in derselben Weise verfügbar sind wie in Imunify360. Echtzeitprüfung kann neue oder veränderte Dateien zeitnah erfassen; Proactive Defense betrachtet PHP-Ausführung als eigene Eingriffsstelle. Beide Funktionen ergänzen planbare Datei-Scans, machen diese aber weder überflüssig noch ersetzen sie die Wartung der Anwendungen.

Auch die Imunify Security Plugin genannte WordPress-Erweiterung ist kein eigenständiger Ersatz für den Server-Agent. Sie wird durch den Imunify-Agent verwaltet und nicht über das WordPress.org-Verzeichnis ausgeliefert. Im WordPress-Backend kann sie Scan- und Schutzinformationen zugänglich machen; welche Funktionen erscheinen, hängt jedoch vom eingesetzten Imunify-Produkt und den jeweils erforderlichen Versionen von Agent und Erweiterung ab.

Für die Betriebsdokumentation empfiehlt sich daher eine klare Bestandsaufnahme: Produktvariante, installierte Agent-Version, Hosting-Panel und aktivierte Schutzmodule gehören zusammen in eine Änderungsdokumentation. Ein WordPress-Administrator kann dann Meldungen im Backend einordnen, ohne anzunehmen, das Plugin kontrolliere Firewallregeln oder schütze andere Nutzerkonten auf dem Server. Die serverseitige Sicherheitsarchitektur bleibt maßgeblich.

Was Malware-Funde tatsächlich aussagen

Hintergrund- und On-Demand-Scans stellen Funde in der Verwaltungsoberfläche mit Zeitpunkt, Dateipfad und Erkennungsgrund bereit. Diese Angaben schaffen einen Ausgangspunkt für die Triage: Der Pfad ordnet einen Fund einem Kundenkonto und einer Anwendung zu, der Zeitpunkt hilft beim Abgleich mit Deployments, Uploads oder verdächtigen Logeinträgen. Sie ersetzen jedoch keine Prüfung des konkreten Inhalts und seines Entstehungswegs.

Für die Priorisierung ist die Art der Erkennung wichtig. Eingeschleuster Schadcode in einer sonst legitimen Datei spricht häufig dafür, die Herkunft dieser Datei, ihre Änderungen und weitere Manipulationen im gleichen Konto zu untersuchen. Eine als eigenständig schädlich erkannte Datei kann dagegen auf eine abgelegte Webshell, einen Dropper oder ein unerwünschtes Administrationstool hinweisen. Beide Fälle verlangen Kontext statt automatischer Schlussfolgerungen.

Ein Fund beweist weder, dass jede Datei im Account kompromittiert ist, noch beschreibt er automatisch den Umfang eines Einbruchs. Umgekehrt belegt ein fundfreier Scan nicht die vollständige Unversehrtheit: Neuartige Exploits, verschleierter Code oder Persistenz außerhalb der erfassten Stelle können zusätzliche Untersuchung erfordern. Auch fehlende WAF- oder Scanner-Erkennung ist kein Nachweis dafür, dass ein Angriff nicht stattgefunden hat.

Meldet der Scanner beispielsweise eine PHP-Datei innerhalb eines WordPress-Plugins, sollte der Betreiber zuerst Fundhistorie und Pfad sichern und die Datei mit einer vertrauenswürdigen Herstellerquelle oder einem geprüften Backup vergleichen. Danach sind Plugin-Version, Administratoren, Zugangsdaten und mögliche Backdoors zu prüfen. Für die organisatorische Einbettung mehrerer WordPress-Projekte helfen die Hinweise zu Sicherheitsanforderungen im Blogger-Hosting, ersetzen aber keine fallspezifische Forensik.

Scanmethoden, Voraussetzungen und Reichweite

Die regulären Datei-Scans von Imunify360 prüfen gespeicherte Dateien im Hosting-Bestand. Sie eignen sich für wiederkehrende Hintergrundläufe ebenso wie für eine gezielte Prüfung nach einem Hinweis aus Monitoring oder Support. Ihr Ergebnis betrifft jedoch den untersuchten Dateibestand: Inhalte in einer Datenbank, ein Angriff während eines HTTP-Requests oder ein bereits missbrauchter Zugang benötigen ergänzende Prüfungen und Schutzschichten.

Der Echtzeit-Scan erweitert diese Prüfung auf bestimmte Übertragungswege. Für das Scannen von HTTP- und HTTPS-Uploads nennt die Dokumentation ModSecurity als Voraussetzung; FTP-Uploads setzen Pure-FTPd voraus. Ob diese Dienste aktiv und passend konfiguriert sind, muss daher pro Server geprüft werden. Die Funktion ist nicht allein durch die Installation des Agents automatisch für jeden Upload-Kanal gegeben.

Zur Scanreichweite gehört auch die Archivprüfung. ZIP-Archive werden laut Dokumentation seit Imunify360 6.2 standardmäßig gescannt. Das ist besonders bei Plugin-Paketen, Sicherungsarchiven oder hochgeladenen Erweiterungen nützlich, sagt aber nichts darüber aus, ob eine Anwendung das Archiv später unsicher entpackt oder ob dessen Inhalte fachlich zulässig sind.

Der Malware Database Scanner (MDS) ergänzt Datei-Scans, wenn Schadcode etwa in Beiträgen, Optionen oder Widget-Inhalten eines CMS hinterlegt wurde. Seine dokumentierte Unterstützung beschränkt sich auf WordPress, Joomla und Magento 2. Für eigene Anwendungen, abweichende Datenbankstrukturen oder weitere Shopsysteme darf daraus keine vollständige Datenbankabdeckung abgeleitet werden.

RapidScan und Datenbankprüfungen planen

RapidScan verändert den Ablauf wiederholter Prüfungen, nicht den grundsätzlichen Anspruch eines Malware-Scans. Imunify360 speichert dazu Dateimetadaten und Hashes lokal und gleicht Hashes mit einer cloudgestützten Datenbasis ab. Bei späteren Durchläufen kann die lokale Analyse auf Dateien konzentriert werden, die verändert oder noch unbekannt sind.

Der erste Durchlauf benötigt dabei zunächst eine reguläre Prüfung des Bestands. Der Hersteller nennt für Folgescans eine mögliche Beschleunigung um das Fünf- bis Zwanzigfache. Diese Spanne ist eine situationsabhängige Herstellerangabe, keine belastbare Zusage für jeden Server: Größe und Zusammensetzung des Dateibestands, Änderungsrate, verfügbare I/O-Leistung und Netzwerkbedingungen beeinflussen das Ergebnis.

Für die Planung bedeutet das: Ein Server mit vielen unveränderten Webdateien kann von RapidScan stärker profitieren als ein Konto, das fortlaufend Uploads, Caches oder Protokolldateien erzeugt. Messe deshalb nicht nur die gesamte Laufzeit, sondern dokumentiere vor Änderungen betroffene Pfade, Dateiumsatz und I/O-Wartezeit. So lassen sich Scanfenster und Ausschlüsse anhand konkreter Ursachen statt anhand von Vermutungen festlegen.

Bei manipulierten WordPress-Beiträgen oder eingeschleusten Skripten in Optionen genügt ein reiner Dateiscan möglicherweise nicht. MDS kann für unterstützte WordPress-Datenbanken zunächst im nicht eingreifenden Modus --scan prüfen. Dieser Schritt verändert keine Daten und schafft eine Grundlage, um Fundorte, Auswirkungen auf die Website und die Wiederherstellbarkeit vor einer Entscheidung zu bewerten.

Bereinigung oder Wiederherstellung sind dagegen Eingriffe in produktive Inhalte. Vorher brauchst du ein aktuelles, geprüftes Backup, eine fachliche Freigabe für die betroffene Website und einen Rückfallplan, falls legitime Inhalte verändert werden. Bei vielen getrennten Kundenprojekten hilft eine saubere Kontentrennung, wie sie auch bei Multi-Domain-Hosting wichtig ist: Sie begrenzt Zuständigkeiten und erleichtert die Zuordnung von Funden.

MDS ist kein Ersatz für eine vollständige Incident-Analyse. Wieder auftauchender Datenbankschadcode kann auf ein verwundbares Plugin, kompromittierte Zugangsdaten oder eine Datei-Backdoor hindeuten. Nach einem Fund sollten daher neben den Datenbankinhalten auch CMS, Erweiterungen, Benutzerkonten und die Herkunft des Schreibvorgangs untersucht werden.

WordPress-Integration und kontrollierte WAF-Updates

Die Imunify Security Plugin genannte WordPress-Erweiterung wird durch den Imunify-Agent auf dem Server verwaltet und nicht über das WordPress.org-Verzeichnis ausgeliefert. Sie kann WordPress-Administratoren Statusinformationen und, abhängig vom eingesetzten Imunify-Produkt, weitere Sicherheitsfunktionen im Backend sichtbar machen. Damit ist sie eine Oberfläche und Ergänzung, aber kein Ersatz für die serverseitigen Scan- und Schutzmechanismen.

Für die Basisfunktion nennt die Dokumentation mindestens Imunify360 8.4.1 auf Serverseite. Funktionen wie WAF-Integration oder AI Bot Management sind separat weiterentwickelt und an jeweils benannte Agent- und Plugin-Versionen gebunden. Prüfe daher vor einem Rollout die konkrete Versionskombination, statt aus dem bloßen Vorhandensein des Plugins auf eine bestimmte Schutzfunktion zu schließen.

Auch die WAF sollte als eigene Ebene betrieben werden. Ab imunify360-firewall 8.6.0 ist ein dokumentierter Ablauf verfügbar, um automatische ModSecurity-Regelupdates zu deaktivieren, verfügbare Regelversionen aufzulisten und gezielt eine Version auszuwählen. Das ermöglicht es Hosting-Betreibern, Regeländerungen kontrolliert zu terminieren und bei Bedarf auf einen bekannten Stand zu wechseln.

Ein sinnvoller Ablauf führt eine neue Regelversion zunächst auf einem Staging-Server mit repräsentativen WordPress-Seiten, Shop-Aktionen und Uploads ein. Erst wenn keine relevanten Fehlblockierungen oder Funktionsprobleme erkennbar sind, folgt die gestaffelte Übernahme in die Produktion. Die Versionssteuerung betrifft dabei ModSecurity-Regeln, nicht pauschal Malware-Signaturen, den gesamten Agenten oder andere Imunify-Komponenten.

Kontrollierte WAF-Regelupdates vermeiden nicht jede Störung, schaffen aber nachvollziehbare Zuständigkeiten: Wer prüft Änderungen, welche Anwendungen dienen als Testfälle und wann wird zurückgerollt? Diese Fragen gehören in den Betriebsprozess. Unverändert nötig bleiben zeitnahe CMS- und Erweiterungsupdates, restriktive Rechte sowie getestete Backups, weil keine WAF bekannte Schwachstellen in installierter Software beseitigt.

Malware-Funde sicher prüfen und behandeln

Ein Malware-Fund ist ein Vorgang zur Untersuchung, nicht automatisch eine Löschanweisung. Prüfe zuerst Fundhistorie, Zeitpunkt, vollständigen Pfad und Erkennungsgrund in der Oberfläche. Diese Angaben helfen einzuordnen, ob die Datei zu einem Plugin, Theme, Upload-Verzeichnis oder einer individuell entwickelten Anwendung gehört und ob derselbe Befund bereits zuvor aufgetreten ist.

Vergleiche eine verdächtige PHP-Datei mit einer vertrauenswürdigen Herstellerquelle derselben Version oder mit einem geprüften Backup. Bei Standardkomponenten ist ein sauberer Neuabgleich meist aussagekräftiger als die isolierte Betrachtung einzelner, möglicherweise verschleierter Codezeilen. Sichere den Fund und die zugehörigen Protokolle vor jeder Änderung, damit ein späterer Eintrittsweg noch nachvollzogen werden kann.

Die eigentliche Ursachenanalyse umfasst mehr als den gemeldeten Pfad: Aktualisiere betroffene CMS-, Plugin- und Theme-Versionen, prüfe Benutzerkonten und rotiere bei einem begründeten Verdacht Zugangsdaten. Suche außerdem nach weiteren Webshells, unbekannten Administratoren und auffälligen geplanten Aufgaben. Eine entfernte Datei schließt nicht aus, dass der Angreifer einen zweiten Zugriff hinterlassen hat.

Ein Datenbankfund verlangt besondere Zurückhaltung, weil bereinigende Eingriffe Inhalte oder Einstellungen verändern können. Ein Scan ist zunächst eine Prüfung; Bereinigung oder Wiederherstellung setzen ein verfügbares Backup, eine fachliche Freigabe und einen Rückfallplan voraus. Der Malware Database Scanner unterstützt nur die dokumentierten Datenbankfälle für WordPress, Joomla und Magento 2 und ist keine allgemeine Prüfung beliebiger Anwendungsschemata.

Wird Adminer erkannt, kann das Tool legitim installiert sein, ist aber wegen seines missbrauchsrelevanten Funktionsumfangs ein nachvollziehbarer Fund. Statt eine Erkennungskategorie global auszuschalten, prüfst du Bedarf, Integrität und Zugriffsschutz der konkreten Datei. Ist eine Ausnahme unvermeidbar, begrenzt ein enger Pfad-Ausschluss die Schutzlücke besser als eine kontoweit oder serverweit deaktivierte Erkennung.

Last, Fehlalarme und Persistenz untersuchen

Steigen CPU-Auslastung oder I/O-Wartezeit, sollte ein Ausschluss nicht die erste Maßnahme sein. Erfasse zunächst Scanereignisse, betroffene Pfade, Änderungsraten, aktive Prozesse und den Zeitraum der Last. Erst die zeitliche Korrelation zeigt, ob Real-Time Scanning beteiligt sein könnte oder ob etwa ein Backup, ein Import, fehlerhafte Anwendungen oder ein anderer Dienst die Ressourcen beansprucht.

Häufig beschriebene Logdateien können wiederholt Scanaktivität auslösen und damit eine mögliche Ursache zusätzlicher Last sein. Ein dokumentierter Supportfall behandelt dieses Muster für WordPress-Logdateien, belegt jedoch keine allgemeine Ursache-Wirkungs-Regel für jeden belasteten Server. Prüfe deshalb konkret Dateipfade und Schreibfrequenzen, statt ganze Kundenverzeichnisse vorsorglich vom Malware Scanner auszunehmen.

Ausnahmen brauchen einen eng umrissenen Zweck, eine verantwortliche Person und eine regelmäßige Überprüfung. Für einen legitim erzeugten, sehr aktiven Pfad kann eine begrenzte Ausnahme nach Analyse vertretbar sein. Sie darf aber nicht unbemerkt auf Upload- oder Anwendungsverzeichnisse ausgedehnt werden, in denen Angreifer Dateien ablegen oder verändern könnten.

Wiederkehrende Funde nach einer Bereinigung sprechen für eine Untersuchung auf Persistenz statt für bloßes Nachlöschen. Neben Dateibestand und Datenbank gehören Cronjobs, unbekannte Administratorkonten, Zugangsdaten, Webserver-Logs und laufende Prozesse in die Prüfung. Besonders geplante Aufgaben können Schadcode erneut herunterladen oder eine entfernte Webshell ersetzen.

Imunify360 dokumentiert einen Scan von System- und Benutzer-Crontabs seit Version 6.10 als experimentelle und standardmäßig deaktivierte Funktion. Das erweitert die Prüfoberfläche, ersetzt aber keine manuelle Bewertung eines auffälligen Jobs. Vor einer Aktivierung prüfst du Last, Kompatibilität und die Auswirkungen auf den eigenen Betriebsablauf; eine pauschale Aktivierung für jede Hosting-Umgebung folgt daraus nicht.

Betrieb, Migration und Rollout entscheiden

Für einen kleinen Server mit wenigen Websites können planbare Hintergrundscans, nachvollziehbare Benachrichtigungen und eine manuelle Freigabe von Maßnahmen ausreichen. In Reseller- und Shared-Hosting-Umgebungen wachsen dagegen die Anforderungen an Eskalationsabläufe: Wer bewertet Funde, wer kontaktiert Kunden, wer darf Ausnahmen setzen und wann wird ein Konto eingeschränkt? Dokumentierte Zuständigkeiten verhindern, dass bereinigende Eingriffe oder Sicherheitslücken zwischen Support und Administration liegen bleiben.

Echtzeitschutz, Scanintervalle und Benachrichtigungen müssen zur Änderungsrate und zu den Ressourcen des Servers passen. Viele unabhängige Kundenkonten profitieren von konsistenten Verfahren und nachvollziehbarer Protokollierung. Ein einzelnes, geschäftskritisches Projekt benötigt oft zusätzlich einen abgestimmten Wartungs- und Freigabeprozess. Grundlegende Schutzmaßnahmen wie Updates, minimale Rechte und getestete Backups bleiben davon unabhängig erforderlich.Kriterien für die Auswahl eines passenden Webhosting-Angebots

Das Produktions-Repository und Testing-Installationen sind strikt zu trennen. Der Hersteller rollt stabile Versionen im Produktionskanal schrittweise aus und nennt dafür einen Zeitraum von bis zu rund zwei Wochen. Eine Funktion, die nur im Testing-Repository oder nach einer Installation mit --beta sichtbar ist, gilt daher nicht automatisch als allgemein stabil verfügbar.

Ein kontrollierter Rollout beginnt mit Versionserfassung und einem repräsentativen Staging- oder Pilotserver. Nach dem Update prüfst du Agent-Status, Paketverwaltung, auffällige Logs und die für Kunden wichtigen Funktionen. Erst bei unauffälligem Verlauf folgt die gestaffelte Ausbringung. Das reduziert nicht jedes Risiko, macht Abweichungen aber früher sichtbar und erleichtert eine gezielte Reaktion.

Die freiwillige Patchman-Migration ist eine Betriebsentscheidung, keine automatische Modernisierung. Nach der Migration lassen sich Dateien nicht mehr aus der bisherigen Patchman-Quarantäne wiederherstellen; Imunify erstellt laut Dokumentation Sicherungen bereinigter Dateien. Vor einer Umstellung sollten Betreiber deshalb Aufbewahrung, Wiederherstellungswege, Kundenkommunikation und Zuständigkeiten verbindlich klären.

Ein konkretes Updateproblem bei imunify-common 1.3.21-1 auf CloudLinux 8 mit Berkeley-DB-basierter RPM-Datenbank wurde laut Hersteller ab 1.3.22-2 behoben. Daraus folgt kein generelles Argument gegen Updates. Es unterstreicht jedoch, warum Wartungsfenster, dokumentierte Versionen und Nachkontrollen der Paketverwaltung zu einem professionellen Updateverfahren gehören.