Imunify360 Security Suite

Imunify360 ist eine erweiterte mehrschichtige Sicherheitsplattform für Webserver und nutzt hochgradig maßgeschneiderte und integrierte Komponenten für proaktiven Echtzeit-Webseitenschutz und Webserver-Sicherheit. Diese Elemente sind nahtlos integriert und sorgen für eine einwandfreie Kompatibilität, um alle Bedrohungen, denen ein Web-Hosting-Dienst ausgesetzt ist, sofort zu erkennen, zu beheben und zu schützten.

Bei unseren Einzel- und Multitarifen ist Imunify360 bereits enthalten. Managed Server Kunden können Imunify360 im Kundencenter als Addon bestellen.

Imunify360 nutzt eine fortschrittliche Firewall/WAF mit Regeln für maschinelles Lernen, automatisches Scannen und Entfernen von Viren und Malware, proaktiver Schutz und Blockierung bösartiger PHP-Skripte ganz ohne Latenz. Es stoppt somit die neuesten Angriffstypen, wie Brute-Force-Angriffe auf Netzwerk- und HTTP-Ebene, Ausnutzung von Sicherheitslücken, einschließlich 0-Day-Angriffen, DoS-Angriffe, Port-Scanning und viele andere. Durch die Cloud-Heuristik und einer künstlichen Intelligenz für Bedrohungen, schützt Imunify360 auch direkt den Server, wenn es auf anderen Installationen Angriffe erkennt.

Alle Funktionen von Imunify360 im Überblick:

• Web Application Firewall (WAF) / Layer 7 Firewall): Imunify360 bietet eine leistungsstarke WAF, die eine zusätzliche Schutzebene für Webanwendungen bereitstellt. Sie überwacht den eingehenden und ausgehenden Datenverkehr, erkennt und blockiert schädlichen Code sowie Angriffsversuche.
• Intrusion Detection and Protection System (IDS/IPS): Das IDS/IPS-Modul überwacht den Serververkehr auf verdächtige Aktivitäten und Angriffsversuche. Es erkennt bekannte Angriffsmuster und reagiert entsprechend, um den Server zu schützen.
• Proaktive Verteidigung: Imunify360 verwendet eine Reihe von proaktiven Verteidigungsmechanismen, um Zero-Day-Angriffe und neu auftretende Bedrohungen abzuwehren. Dazu gehören Verhaltensanalyse, Sandbox-Technologien und intelligente Algorithmen zur Erkennung von Malware.
• Malware-Scans und automatische Bereinigung: Imunify360 führt regelmäßige Scans des Servers durch, um nach bekannten Malware-Signaturen zu suchen. Wenn Malware gefunden wird, bietet es eine automatische Bereinigungsfunktion, um schädlichen Code zu entfernen und die Sicherheit der Websites wiederherzustellen.
• WordPress Datenbank Malware-Scanner: Der WordPress-Datenbank-Scanner, prüft WordPress-Einträge auf böswillige Einfügungen von Javascript, Iframes und anderen Inhalten.
• Echtzeit Malware-Scanner: Wenn eine Datei auf dem Server erstellt wird, wird diese gescannt. Wenn sie bösartig ist, wird sie bereinigt. Dies schützt proaktiv vor zerstörerischen Auswirkungen und ist besonders hilfreich für ein bereits infiziertes System, was z.B. von einem anderen Hoster auf die Server von HostPress umgezogen wird.
• Schutz vor Brute-Force-Angriffen: Imunify360 bietet Schutzmechanismen gegen Brute-Force-Angriffe auf gängige CMS-Plattformen wie WordPress, Joomla und Drupal. Es überwacht fehlgeschlagene Anmeldeversuche und blockiert automatisch verdächtige IP-Adressen.
• Reputationssystem: Imunify360 verfügt über ein integriertes Reputationssystem, das verdächtige IP-Adressen und bösartige Domains identifiziert. Dadurch können potenzielle Bedrohungen frühzeitig erkannt und blockiert werden.
• WebShield: Die WebShield-Komponente kümmert sich um den CDN- und Proxy-Verkehr, indem sie die echten IP-Adressen der Angreifer ermittelt und diese IP-Adressen dann von denen legitimer Benutzer unterscheidet. Webshield führt verdächtige IP-Adressen in einer grauen Liste und stellt dann Splash-Screens und CAPTCHA-Herausforderungen bereit, die verhindern, dass böswillige Anfragen Ihr System schädigen oder sogar verlangsamen.
• Echtzeitbenachrichtigungen: Imunify360 sendet auf Wunsch Benachrichtigungen über potenzielle Sicherheitsbedrohungen oder Angriffsversuche in Echtzeit per E-Mail. 
• Zentrales Management-Dashboard: Imunify360 bietet ein benutzerfreundliches zentrales Management-Dashboard, über das Administratoren den Sicherheitsstatus des Servers überwachen, Konfigurationen anpassen und Berichte generieren können.
• Diese Funktionen stellen nur einen Überblick über die Möglichkeiten von Imunify360 dar. Die Software wird kontinuierlich weiterentwickelt, um den sich ständig ändernden Bedrohungslandschaften gerecht zu werden und den Schutz von Webhosting-Servern zu verbessern.

Darüber hinaus wurde Imunify360 mit Heuristiken ausgestattet, die in der Cloud laufen, um es noch stärker zu machen. Server unter dem Schutz von Imunify360 erhalten eine kollektive Herdenimmunität, da sie Bedrohungsinformationen in Echtzeit austauschen.

Download: PDF Broschüre Imunify360

Mehr Infos zu Imunify360 direkt beim Anbieter:

https://www.imunify360.com/security-privacy/

Auswirkung auf Suchmaschinen-Crawler und eigene Bots

Die WebShield-Komponente von Imunify360 kann bei verdächtigem oder ungewöhnlichem Zugriffsverhalten kurzzeitig eine Verifizierungsseite anzeigen („Please wait while your request is being verified“), bevor die eigentliche Seite ausgeliefert wird. Das betrifft in seltenen Fällen auch automatisierte Zugriffe wie Suchmaschinen-Crawler oder eigene Test-Tools.

• Für gängige Suchmaschinen wie Google ist das in der Regel unproblematisch, solange robots.txt und die Sitemap grundsätzlich erreichbar bleiben.
• In seltenen Fällen kann auch ein legitimer Bot (z. B. Googlebot) fälschlich als verdächtig eingestuft und kurzzeitig blockiert werden.
• Solltest du einen dauerhaften Rückgang der Crawling-Aktivität oder wiederholte Indexierungsprobleme feststellen, kann dies ein Hinweis auf eine zu aggressive Einstufung durch WebShield sein – wende dich in diesem Fall an unseren Support.

Monitoring-Tool wird fälschlich als Downtime gemeldet? User-Agent-Ausnahme statt reiner IP-Freigabe

Wenn du ein externes Uptime- oder Monitoring-Tool (z. B. ManageWP, GoDaddy Uptime Monitor oder ähnliche Dienste) einsetzt und dieses wiederholt Downtime meldet, obwohl deine Website erreichbar ist, kann das an der serverseitigen Sicherheitsschicht (Imunify360) liegen. Automatisierte, wiederkehrende Zugriffe von Monitoring-Diensten werden von der Firewall unter Umständen als verdächtig eingestuft und blockiert.

Warum eine reine IP-Freigabe oft nicht dauerhaft hilft

Viele Monitoring-Anbieter prüfen deine Website nicht immer von derselben IP-Adresse aus, sondern wechseln zwischen mehreren Servern bzw. Standorten. Eine einmalige Freigabe einer einzelnen IP-Adresse löst das Problem daher oft nur kurzfristig. Zudem ist eine dauerhafte, globale IP-Freigabe auf Shared-Hosting aus Sicherheitsgründen technisch nicht vorgesehen.

Die robustere Lösung: Ausnahme über den User-Agent

Monitoring-Dienste senden bei ihren Anfragen in der Regel einen eindeutig erkennbaren User-Agent-String mit (z. B. „ManageWP-UptimeMonitoring“ oder „GoDaddy Uptime Monitor“). Der HostPress Support kann für solche bekannten, eindeutigen User-Agents eine serverseitige Ausnahmeregel einrichten, damit Anfragen mit diesem Kennzeichen nicht als verdächtig eingestuft und blockiert werden – unabhängig davon, von welcher IP-Adresse sie stammen.

Was du tun kannst

• Prüfe in den Einstellungen deines Monitoring-Tools, ob der genaue User-Agent-String und/oder eine Liste der verwendeten IP-Adressen einsehbar ist.
• Reduziere versuchsweise das Prüfintervall (z. B. von 1 auf 5 Minuten), falls möglich – das verringert die Anzahl automatisierter Anfragen.
• Kontaktiere den HostPress Support mit dem Namen des Monitoring-Tools und, falls bekannt, dem verwendeten User-Agent-String bzw. den IP-Adressen. Das Team prüft dann, ob bereits blockierte IPs freigegeben werden müssen und ob zusätzlich eine dauerhafte User-Agent-Ausnahmeregel eingerichtet werden kann.

IP-Adresse für eigene automatisierte Tools freigeben lassen

Nutzt du eigene automatisierte Zugriffe von deinem Rechner oder Server aus – zum Beispiel eine Testsuite mit Playwright, ein Monitoring- oder Uptime-Tool – kann es passieren, dass Imunify360 diese Zugriffe vorübergehend blockiert.

• Eine dauerhafte, permanente Whitelist für einzelne IP-Adressen ist auf Shared-Hosting technisch nicht möglich.
• Wird deine IP blockiert, kann unser Support die Firewall-Einträge prüfen und die IP bei Bedarf manuell freigeben.
• Teile dem Support dafür deine aktuelle, öffentliche IP-Adresse mit.
• Beachte: Ändert sich deine IP-Adresse häufig (z. B. bei dynamischer IP-Vergabe durch deinen Internetanbieter oder in Cloud-CI-Umgebungen), ist eine dauerhaft zuverlässige Freigabe entsprechend schwieriger umzusetzen.

Hinweise

Die Verifizierungsseite von WebShield schützt vor Bots mit schädlicher Absicht und wirkt sich normalerweise nicht auf reguläres Suchmaschinen-Crawling aus. Für eigene automatisierte Tools kann unser Support einzelne IP-Adressen manuell prüfen und freigeben – eine dauerhafte Whitelist ist im Shared-Hosting jedoch nicht vorgesehen.

Sonderfall: Server blockiert eigene Cronjobs oder interne API-Aufrufe an sich selbst

Ein Sonderfall der oben beschriebenen Blockierung tritt auf, wenn nicht ein externes Tool, sondern dein Server sich selbst kontaktiert – zum Beispiel über einen Cronjob, der regelmäßig eine eigene REST-Schnittstelle deiner Website aufruft, oder über eine automatische Cache-Leerung nach dem Speichern in einem Redaktionswerkzeug. Imunify360 kann solche Selbstaufrufe fälschlich als fremden Bot einstufen und ab wenigen Anfragen pro Minute mit einer Meldung wie „Rate limit exceeded. Please retry later“ blockieren.

Woran du dieses Szenario erkennst

• Ein eigener Cronjob oder ein internes Skript ruft mehrfach pro Minute eine Schnittstelle derselben Website auf.
• Nach wenigen Anfragen erscheint die Meldung „Rate limit exceeded. Please retry later“ statt der erwarteten Antwort.
• Automatisierte Folgeaktionen bleiben unbemerkt aus – zum Beispiel wird der Cache nach dem Speichern nicht geleert, sodass veraltete Inhalte online bleiben.
• Das Deaktivieren einzelner WAF-Regeln (z. B. „WordPress WAF aktivieren“) behebt das Problem nicht; erst das komplette Deaktivieren des Sicherheits-Plugins hilft testweise weiter.

Was du tun kannst

1. Kontaktiere unseren Support und beschreibe, dass es sich um Selbstaufrufe deines eigenen Servers an die eigene Schnittstelle handelt (nicht um Zugriffe von einer externen IP-Adresse).
2. Der Support kann die Server-IP für diese internen Selbstaufrufe gezielt in der Imunify360-Firewall freigeben.
3. Aktiviere dein Sicherheits-Plugin nach der Freigabe wieder vollständig, statt es dauerhaft deaktiviert zu lassen.

Wichtiger Hinweis: Keine eigenen Bypass-Dateien verwenden

Versuche nicht, den Schutz über eine eigene, selbst erstellte Datei zu umgehen, die den Bot-Schutz für interne Aufrufe deaktiviert (z. B. ein eigenes mu-Plugin). Unser Malware-Scanner erkennt Code, der Sicherheitsfunktionen gezielt deaktiviert, zuverlässig als verdächtig und bereinigt bzw. leert eine solche Datei automatisch bei jedem Scan – die Änderung geht dadurch immer wieder verloren. Wende dich stattdessen an den Support, damit die Freigabe direkt und dauerhaft in der Firewall-Konfiguration erfolgt.

Sonderfall: Automatischer Bot-Schutz kollidiert mit eigenem Security-Plugin

Neben den oben beschriebenen Fällen kann es vorkommen, dass du auf deiner Website (oder in Support-Antworten) auf einen automatisch ausgerollten, zusätzlichen Bot-Schutz stößt, den du nicht selbst installiert hast. HostPress rollt diesen Schutz sukzessive auf allen Webseiten aus, um aggressive Bots und automatisierte Angriffe bereits auf Plattformebene abzufangen – zusätzlich zu Imunify360.

Betreibst du parallel dazu ein eigenes, zusätzlich installiertes Security-Plugin (z. B. Wordfence, All In One WP Security oder ein anderes Firewall-/Login-Schutz-Plugin), können beide Systeme gleichzeitig auf denselben Datenverkehr reagieren. Das kann zu unerwarteten Fehlermeldungen, doppelten Sperren oder widersprüchlichem Verhalten führen.

Woran du dieses Szenario erkennst

• Fehler oder Blockierungen treten erst auf, seit der plattformseitige Bot-Schutz auf deiner Website aktiv ist.
• Dein eigenes Security-Plugin protokolliert Blockierungen oder Konflikte, die sich nicht durch dessen eigene Einstellungen erklären lassen.
• Du hast keine konkrete Fehlermeldung oder URL zur Hand, wodurch sich die Ursache im ersten Kontakt mit dem Support noch nicht abschließend klären lässt.

Was du tun kannst

1. Notiere dir eine konkrete Fehlermeldung, eine betroffene URL und den ungefähren Zeitpunkt, sobald ein Konflikt auftritt – das erleichtert die Diagnose erheblich.
2. Prüfe, ob der Fehler auch ohne dein eigenes Security-Plugin auftritt, indem du es kurzzeitig testweise deaktivierst.
3. Kontaktiere unseren Support mit den gesammelten Informationen (Fehlermeldung, URL, Zeitpunkt, genutztes Security-Plugin). Wir prüfen dann, ob eine gezielte Anpassung auf Serverebene möglich ist, damit beide Systeme reibungslos zusammenarbeiten.
4. Du musst dein eigenes Security-Plugin in der Regel nicht dauerhaft deinstallieren – meist reicht eine gezielte Abstimmung zwischen den beiden Schutzsystemen.

Wenn du grundsätzlich unsicher bist, ob du für deine Website überhaupt ein zusätzliches, eigenes Security-Plugin benötigst, sprich uns gerne an: Da der plattformseitige Bot-Schutz automatisch für alle Webseiten bereitgestellt wird, ist ein zusätzliches Plugin nicht in jedem Fall notwendig.

Sonderfall: REST-API liefert 401, obwohl die Firewall nicht die Ursache ist

Wenn eine externe Anwendung über die WordPress REST API auf deine Website zugreifen soll und dabei konstant mit HTTP 401 abgewiesen wird, liegt der Verdacht nahe, dass eine serverseitige Firewall oder WAF automatisierte Zugriffe blockiert. In vielen Fällen liegt die Ursache jedoch nicht am Server, sondern an einem WordPress-Plugin, das den Zugriff auf die REST API für nicht eingeloggte bzw. nicht authentifizierte Anfragen standardmäßig einschränkt.

Woran du dieses Szenario erkennst

• Der 401-Fehler tritt bereits auf, bevor WordPress vollständig geladen wird, obwohl /wp-json im Browser normal erreichbar ist.
• Die Logs deines Sicherheits-Plugins zeigen keine Einträge zu den blockierten Anfragen.
• Normale Anmeldungen und Browserzugriffe auf die Website funktionieren einwandfrei; nur automatisierte bzw. externe API-Zugriffe scheitern.

Was du tun kannst

1. Prüfe deine installierten Plugins auf Einstellungen, die den REST-API-Zugriff für Gäste bzw. nicht eingeloggte Nutzer einschränken (häufig in Sicherheits- oder Firewall-Plugins zu finden, die zusätzlich zur HostPress-Infrastruktur auf WordPress-Ebene laufen).
2. Schalte das jeweilige Plugin testweise aus bzw. gib den benötigten REST-API-Endpunkt gezielt frei, um zu prüfen, ob der Fehler dadurch verschwindet.
3. Erst wenn der Fehler auch bei deaktivierten Plugins weiterhin auftritt, ist eine Prüfung der serverseitigen WAF/Imunify360-Logs durch den Support sinnvoll.

Fazit & Support-Hinweis

Blockiert Imunify360 nicht nur externe Tools, sondern auch Selbstaufrufe deines eigenen Servers an seine eigene Schnittstelle, kannst du das nicht dauerhaft selbst über Plugin-Einstellungen oder eigene Bypass-Dateien lösen. Wende dich mit einer kurzen Beschreibung des Anwendungsfalls an unseren Support – wir richten die passende Freigabe in der Firewall ein.