Imunify360-malwarescanner: functies, updates en beperkingen

Imunify360 als meerlaagse beveiliging voor hosting

Imunify360 is geen op zichzelf staande viruscontrole, maar een Linux-beveiligingsoplossing met meerdere beveiligingslagen. De Malwarescanner controleert bestanden op bekende of verdachte inhoud. De firewall en het IDS/IPS monitoren en beperken verdachte netwerkactiviteiten, terwijl een Web Application Firewall (kortweg WAF) HTTP-verzoeken vóór de toepassing aan de hand van regels beoordeelt. Reputatiecontroles leveren aanvullende signalen voor het classificeren van bronnen en activiteiten.

Deze indeling is cruciaal voor hostingproviders, omdat de lagen op verschillende punten in werking treden. Een HTTP-aanval op een bekend kwetsbaar punt kan al bij de WAF worden tegengehouden, voordat WordPress, Joomla of Magento het verzoek verwerkt. Een schadelijke upload wordt daarentegen pas relevant bij de bestandscontrole. Als er een PHP-webshell wordt uitgevoerd, kan Proactieve verdediging verdacht gedrag tijdens de uitvoering van PHP aanpakken; het is echter geen analyse achteraf van het gehele incident.

Het model heet Verdediging in de diepte: Een enkele kwetsbaarheid of een over het hoofd gezien bevinding mag niet op zichzelf bepalend zijn voor de veiligheid van een klantenaccount. Malware-detectie kan bestaande schadelijke code zichtbaar maken, maar voorkomt niet noodzakelijkerwijs de oorspronkelijke exploit. Evenzo kan een WAF een aanval blokkeren zonder reeds opgeslagen bestanden of gemanipuleerde database-inhoud te verwijderen.

Geen van deze niveaus vervangt de fundamentele beheeractiviteiten. De kern van het CMS, plug-ins, thema’s en uitbreidingen hebben tijdige beveiligingsupdates nodig; restrictieve bestandsrechten en afzonderlijke inloggegevens beperken de gevolgen van een gehackt account. Gecontroleerde back-ups maken herstel mogelijk, en bij een bevinding maakt pas een incidentanalyse duidelijk hoe de inbraak is gebeurd, wat de omvang ervan is en of er sprake is van persistentie. Imunify360 biedt hiervoor waarschuwings- en detectiesignalen, maar geen volledig bewijs dat de omgeving veilig is.

Het verschil tussen Imunify360, ImunifyAV en ImunifyAV+

Functielijsten moeten worden toegewezen aan het betreffende product. Imunify360 is de uitgebreidere beveiligingsoplossing voor servers; ImunifyAV en ImunifyAV+ zijn afzonderlijke producten met functies op het gebied van malware. Wie deze namen op één lijn stelt, zou bijvoorbeeld een bestaande scanfunctie kunnen verwarren met firewall-, realtime- of PHP-beveiliging en daaruit verkeerde verwachtingen kunnen afleiden voor een managed- of reseller-server.

Van bijzonder belang is dat realtime-scanning en Proactive Defense volgens de documentatie van de fabrikant niet op dezelfde manier beschikbaar zijn in ImunifyAV respectievelijk ImunifyAV+ als in Imunify360. Realtime-scanning kan nieuwe of gewijzigde bestanden snel detecteren; Proactive Defense beschouwt de uitvoering van PHP als een apart interventiepunt. Beide functies vormen een aanvulling op geplande bestandsscans, maar maken deze niet overbodig en vervangen evenmin het onderhoud van de applicaties.

Ook de WordPress-uitbreiding die de Imunify Security Plugin wordt genoemd, is geen op zichzelf staande vervanging voor de server-agent. Deze wordt beheerd door de Imunify-agent en wordt niet via de WordPress.org-directory geleverd. In de WordPress-backend kan deze plug-in scan- en beveiligingsinformatie beschikbaar maken; welke functies worden weergegeven, hangt echter af van het gebruikte Imunify-product en de vereiste versies van de agent en de plug-in.

Voor de bedrijfsdocumentatie is het daarom raadzaam om een duidelijk overzicht op te stellen: productvariant, geïnstalleerde agentversie, hostingpaneel en geactiveerde beveiligingsmodules horen allemaal thuis in een wijzigingsdocumentatie. Een WordPress-beheerder kan dan meldingen in de backend indelen zonder ervan uit te gaan dat de plug-in firewallregels controleert of andere gebruikersaccounts op de server beschermt. De beveiligingsarchitectuur aan de serverzijde blijft doorslaggevend.

Wat de ontdekking van malware eigenlijk betekent

Achtergrond- en on-demand-scans geven de gevonden items weer in de beheerinterface, samen met het tijdstip, het bestandspad en de reden voor de detectie. Deze gegevens vormen een uitgangspunt voor de triage: het pad koppelt een vondst aan een klantaccount en een applicatie, het tijdstip helpt bij het afstemmen met implementaties, uploads of verdachte logboekvermeldingen. Ze vervangen echter geen controle van de concrete inhoud en de manier waarop deze is ontstaan.

Voor het stellen van prioriteiten is de aard van de detectie van belang. Als er schadelijke code is binnengeslopen in een verder legitiem bestand, is dat vaak een aanwijzing om de herkomst van dit bestand, de wijzigingen die erin zijn aangebracht en verdere manipulaties binnen hetzelfde account te onderzoeken. Een bestand dat op zichzelf als schadelijk wordt herkend, kan daarentegen wijzen op een achtergelaten webshell, een dropper of een ongewenste beheertool. In beide gevallen is context nodig in plaats van automatische conclusies.

Een bevinding bewijst noch dat elk bestand in het account is gecompromitteerd, noch geeft deze automatisch de omvang van een inbraak weer. Omgekeerd bewijst een scan zonder bevindingen niet dat alles volledig intact is: nieuwe exploits, verborgen code of persistentie buiten het onderzochte gebied kunnen nader onderzoek vereisen. Ook het ontbreken van WAF- of scannerdetectie is geen bewijs dat er geen aanval heeft plaatsgevonden.

Als de scanner bijvoorbeeld een PHP-bestand binnen een WordPress-plug-in signaleert, moet de beheerder eerst de zoekgeschiedenis en het pad opslaan en het bestand vergelijken met een betrouwbare bron van de fabrikant of een gecontroleerde back-up. Vervolgens moeten de plug-inversie, beheerders, inloggegevens en mogelijke achterdeurtjes worden gecontroleerd. Voor de organisatorische integratie van meerdere WordPress-projecten bieden de aanwijzingen over Veiligheidseisen bij Blogger-hosting, maar vormen geen vervanging voor een op het specifieke geval afgestemd forensisch onderzoek.

Scanmethoden, vereisten en bereik

De reguliere bestandsscans van Imunify360 controleren opgeslagen bestanden in de hostingomgeving. Ze zijn geschikt voor terugkerende achtergrondprocessen, maar ook voor een gerichte controle naar aanleiding van een melding vanuit de monitoring of de support. Het resultaat heeft echter alleen betrekking op de onderzochte bestanden: inhoud in een database, een aanval tijdens een HTTP-verzoek of een reeds misbruikte toegang vereisen aanvullende controles en beveiligingslagen.

De Realtime-scan breidt deze controle uit naar bepaalde overdrachtskanalen. Voor het scannen van HTTP- en HTTPS-uploads wordt in de documentatie ModSecurity als vereiste genoemd; voor FTP-uploads is Pure-FTPd vereist. Of deze diensten actief en correct zijn geconfigureerd, moet daarom per server worden gecontroleerd. De functie is niet automatisch beschikbaar voor elk uploadkanaal, alleen door de installatie van de agent.

Tot het scanbereik behoort ook de controle van archieven. Volgens de documentatie worden ZIP-archieven sinds Imunify360 6.2 standaard gescand. Dit is vooral handig bij plug-inpakketten, back-uparchieven of geüploade uitbreidingen, maar zegt niets over de vraag of een toepassing het archief later op een onveilige manier uitpakt of dat de inhoud ervan technisch aanvaardbaar is.

De Malware-databasescanner (MDS) vult bestandsscans aan wanneer schadelijke code bijvoorbeeld is achtergelaten in berichten, instellingen of widget-inhoud van een CMS. De gedocumenteerde ondersteuning is beperkt tot WordPress, Joomla en Magento 2. Voor eigen toepassingen, afwijkende databasestructuren of andere webshopsystemen mag hieruit geen volledige databasedekking worden afgeleid.

RapidScan en databasecontroles plannen

RapidScan verandert de werkwijze bij herhaalde scans, niet de fundamentele doelstelling van een malwarescan. Imunify360 slaat hiervoor bestandsmetadata en hashes lokaal op en vergelijkt de hashes met een cloudgebaseerde database. Bij latere scans kan de lokale analyse worden gericht op bestanden die zijn gewijzigd of nog onbekend zijn.

De eerste doorloop vereist daarbij eerst een reguliere controle van de bestanden. De fabrikant geeft aan dat volgende scans vijf tot twintig keer sneller kunnen verlopen. Deze marge is een situatieafhankelijke specificatie van de fabrikant, geen bindende toezegging voor elke server: de omvang en samenstelling van de bestanden, de wijzigingsfrequentie, de beschikbare I/O-capaciteit en de netwerkomstandigheden beïnvloeden het resultaat.

Voor de planning betekent dit: een server met veel ongewijzigde webbestanden kan door RapidScan meer voordeel opleveren dan een account dat voortdurend uploads, cachebestanden of logbestanden genereert. Meet daarom niet alleen de totale looptijd, maar documenteer vóór wijzigingen de betrokken paden, het aantal bestanden en de I/O-wachttijd. Zo kunnen scanvensters en uitsluitingen worden vastgesteld op basis van concrete oorzaken in plaats van op basis van veronderstellingen.

Bij gemanipuleerde WordPress-berichten of in de instellingen gesmokkelde scripts is een gewone bestandsscan mogelijk niet voldoende. MDS kan voor ondersteunde WordPress-databases in eerste instantie in de niet-ingrijpende modus worden gebruikt --scan controleren. Deze stap heeft geen invloed op de gegevens en biedt een basis om vindplaatsen, de gevolgen voor de website en de herstelbaarheid te beoordelen voordat er een beslissing wordt genomen.

Opschoning of herstel zijn daarentegen ingrepen in productieve inhoud. Vooraf heb je een actuele, gecontroleerde back-up nodig, een technische goedkeuring voor de betreffende website en een noodplan voor het geval er legitieme inhoud wordt gewijzigd. Bij veel afzonderlijke klantprojecten helpt een duidelijke scheiding van de inhoud, zoals die ook wordt toegepast bij Hosting voor meerdere domeinen Belangrijk is: het beperkt de bevoegdheden en maakt het gemakkelijker om vondsten toe te wijzen.

MDS is geen vervanging voor een volledige incidentanalyse. Terugkerende schadelijke code in de database kan wijzen op een kwetsbare plug-in, gecompromitteerde inloggegevens of een backdoor in een bestand. Na een vondst moeten daarom naast de inhoud van de database ook het CMS, de uitbreidingen, de gebruikersaccounts en de herkomst van de schrijfbewerking worden onderzocht.

WordPress-integratie en gecontroleerde WAF-updates

De WordPress-uitbreiding met de naam Imunify Security Plugin wordt beheerd door de Imunify-agent op de server en wordt niet via de WordPress.org-directory geleverd. Deze extensie kan WordPress-beheerders statusinformatie en, afhankelijk van het gebruikte Imunify-product, aanvullende beveiligingsfuncties in de backend weergeven. Daarmee is het een interface en aanvulling, maar geen vervanging voor de scan- en beveiligingsmechanismen aan de serverzijde.

Voor de basisfunctie vermeldt de documentatie ten minste Imunify360 8.4.1 aan de serverzijde. Functies zoals WAF-integratie of AI Bot Management zijn afzonderlijk verder ontwikkeld en gekoppeld aan specifiek genoemde agent- en plug-inversies. Controleer daarom vóór een uitrol de concrete versiecombinatie, in plaats van op basis van de loutere aanwezigheid van de plug-in te concluderen dat een bepaalde beveiligingsfunctie aanwezig is.

Ook de WAF moet als een afzonderlijk niveau worden beheerd. Vanaf imunify360-firewall 8.6.0 Er is een gedocumenteerde procedure beschikbaar om automatische updates van ModSecurity-regels uit te schakelen, beschikbare regelversies weer te geven en gericht een versie te selecteren. Hierdoor kunnen hostingproviders wijzigingen in de regels op een gecontroleerde manier inplannen en indien nodig overschakelen naar een bekende versie.

Een verstandige werkwijze houdt in dat een nieuwe regelversie eerst wordt geïmplementeerd op een staging-server met representatieve WordPress-pagina’s, winkelacties en uploads. Pas wanneer er geen relevante valse blokkades of functionele problemen worden vastgesteld, volgt de gefaseerde overgang naar de productieomgeving. De versiebeheerregeling heeft daarbij betrekking op ModSecurity-regels, niet in het algemeen op malwaresignaturen, de volledige agent of andere Imunify-componenten.

Gecontroleerde Updates van de WAF-regels Ze voorkomen niet elke storing, maar zorgen wel voor duidelijke verantwoordelijkheden: wie controleert wijzigingen, welke applicaties dienen als testcases en wanneer wordt er teruggedraaid? Deze vragen horen thuis in het operationele proces. Tijdige updates van het CMS en uitbreidingen, restrictieve rechten en geteste back-ups blijven onverminderd noodzakelijk, omdat geen enkele WAF bekende kwetsbaarheden in geïnstalleerde software wegneemt.

Malware-vondsten veilig controleren en afhandelen

De detectie van malware is een onderzoeksstap en betekent niet automatisch dat het bestand moet worden verwijderd. Controleer eerst de detectiegeschiedenis, het tijdstip, het volledige pad en de reden voor detectie in de interface. Deze gegevens helpen je te bepalen of het bestand bij een plug-in, thema, uploadmap of een op maat ontwikkelde applicatie hoort en of dezelfde bevinding al eerder is opgetreden.

Vergelijk een verdacht PHP-bestand met een betrouwbare bron van de fabrikant van dezelfde versie of met een gecontroleerde back-up. Bij standaardcomponenten is een grondige hervergelijking meestal veelzeggender dan het afzonderlijk bekijken van individuele, mogelijk verhulde coderegels. Leg de vondst en de bijbehorende logbestanden vast vóór elke wijziging, zodat een latere infectieroute nog kan worden achterhaald.

De daadwerkelijke oorzaakanalyse omvat meer dan alleen het gemelde pad: werk de betreffende CMS-, plug-in- en themaversies bij, controleer gebruikersaccounts en wissel bij een gegrond vermoeden de inloggegevens af. Zoek bovendien naar andere webshells, onbekende beheerders en opvallende geplande taken. Het feit dat een bestand is verwijderd, sluit niet uit dat de aanvaller een tweede toegangspunt heeft achtergelaten.

Het uitvoeren van een database-scan vereist bijzondere terughoudendheid, omdat corrigerende ingrepen de inhoud of instellingen kunnen wijzigen. Een scan is in eerste instantie een controle; opschoning of herstel vereisen een beschikbare back-up, goedkeuring door een specialist en een noodplan. De Malware Database Scanner ondersteunt alleen de gedocumenteerde databasecases voor WordPress, Joomla en Magento 2 en is geen algemene controle van willekeurige applicatieschema’s.

Als Adminer wordt gedetecteerd, kan de tool legitiem zijn geïnstalleerd, maar is het vanwege de functies die voor misbruik vatbaar zijn een begrijpelijke vondst. In plaats van een detectiecategorie globaal uit te schakelen, controleer je de noodzaak, integriteit en toegangsbeveiliging van het betreffende bestand. Als een uitzondering onvermijdelijk is, beperkt een strikte uitsluiting op padniveau het beveiligingslek beter dan een detectie die per account of per server is uitgeschakeld.

Belasting, valse alarmen en persistentie onderzoeken

Als het CPU-gebruik of de I/O-wachttijd toeneemt, mag uitsluiting niet de eerste maatregel zijn. Leg eerst scangebeurtenissen, de betrokken paden, wijzigingsfrequenties, actieve processen en de duur van de belasting vast. Pas de temporele correlatie laat zien of realtime-scanning hier een rol zou kunnen spelen of dat bijvoorbeeld een back-up, een import, defecte applicaties of een andere dienst de resources in beslag neemt.

Vaak beschreven logbestanden kunnen herhaaldelijk scanactiviteit veroorzaken en daarmee een mogelijke oorzaak zijn van extra belasting. Een gedocumenteerde supportcase behandelt dit patroon voor WordPress-logbestanden, maar bewijst geen algemene oorzaak-gevolgrelatie voor elke overbelaste server. Controleer daarom specifiek de bestandspaden en schrijffrequenties, in plaats van uit voorzorg hele klantmappen uit de Malwarescanner uit te sluiten.

Uitzonderingen moeten een duidelijk omschreven doel hebben, een verantwoordelijke persoon en een regelmatige controle. Voor een legitiem gegenereerd, zeer actief pad kan een beperkte uitzondering na analyse gerechtvaardigd zijn. Deze mag echter niet onopgemerkt worden uitgebreid naar upload- of applicatiemappen waarin aanvallers bestanden zouden kunnen plaatsen of wijzigen.

Terugkerende bevindingen na een opschoning pleiten voor een onderzoek naar Volharding in plaats van alleen maar te verwijderen. Naast de bestanden en de database moeten ook cronjobs, onbekende beheerdersaccounts, inloggegevens, webserverlogs en actieve processen worden gecontroleerd. Met name geplande taken kunnen opnieuw schadelijke code downloaden of een verwijderde webshell vervangen.

Imunify360 documenteert sinds versie 6.10 een scan van systeem- en gebruikers-crontabs als een experimentele functie die standaard is uitgeschakeld. Dit breidt de controle-interface uit, maar vervangt geen handmatige beoordeling van een verdachte taak. Controleer vóór activering de belasting, compatibiliteit en de gevolgen voor je eigen bedrijfsvoering; dit betekent niet dat de functie standaard voor elke hostingomgeving moet worden geactiveerd.

Beslissingen nemen over de bedrijfsvoering, migratie en implementatie

Voor een kleine server met slechts enkele websites kunnen geplande achtergrondscans, traceerbare meldingen en een handmatige goedkeuring van maatregelen volstaan. In reseller- en shared-hostingomgevingen worden de eisen daarentegen steeds hoger Escalatieprocedures: Wie beoordeelt de vondsten, wie neemt contact op met klanten, wie mag uitzonderingen toestaan en wanneer wordt een account beperkt? Door verantwoordelijkheden vast te leggen, wordt voorkomen dat corrigerende maatregelen of beveiligingslekken tussen de helpdesk en de administratie blijven hangen.

Realtime beveiliging, scanintervallen en meldingen moeten worden afgestemd op de wijzigingsfrequentie en de systeembronnen van de server. Veel onafhankelijke klantaccounts profiteren van consistente procedures en traceerbare logboekregistratie. Een enkel, bedrijfskritisch project vereist vaak bovendien een afgestemd onderhouds- en goedkeuringsproces. Fundamentele beveiligingsmaatregelen zoals updates, minimale rechten en geteste back-ups blijven hiervan onafhankelijk noodzakelijk.Criteria voor het kiezen van een geschikt webhostingpakket

De productierepository en de testomgevingen moeten strikt van elkaar worden gescheiden. De fabrikant rolt stabiele versies stapsgewijs uit in het productiekanaal en geeft daarvoor een termijn van maximaal ongeveer twee weken aan. Een functie die alleen in de testrepository of na een installatie met --beta is zichtbaar, wordt daarom niet automatisch beschouwd als algemeen stabiel beschikbaar.

Een gecontroleerde Uitrol begint met het vaststellen van de versie en een representatieve staging- of pilotserver. Na de update controleer je de status van de agent, het pakketbeheer, opvallende logbestanden en de functies die voor klanten belangrijk zijn. Pas als alles sootloopt, volgt de gefaseerde uitrol. Dit elimineert niet elk risico, maar maakt afwijkingen eerder zichtbaar en vergemakkelijkt een gerichte reactie.

De vrijwillige migratie naar Patchman is een bedrijfsbeslissing, geen automatische modernisering. Na de migratie kunnen bestanden niet meer worden hersteld vanuit de huidige Patchman-quarantaine; volgens de documentatie maakt Imunify back-ups van opgeschoonde bestanden. Voorafgaand aan een overstap moeten beheerders daarom de opslag, herstelprocedures, communicatie met klanten en verantwoordelijkheden bindend vastleggen.

Een concreet updateprobleem bij imunify-common 1.3.21-1 op CloudLinux 8 met een op Berkeley-DB gebaseerde RPM-database is volgens de fabrikant vanaf versie 1.3.22-2 verholpen. Dit is geen algemeen argument tegen updates. Het onderstreept echter wel waarom onderhoudsvensters, gedocumenteerde versies en nacontroles van het pakketbeheer deel uitmaken van een professioneel updateproces.