Imunify360 Malware Scanner: Funktioner, uppdateringar och begränsningar

Imunify360 som flerskiktad säkerhetslösning för webbhotell

Imunify360 är inte en enskild virusskanner, utan en säkerhetslösning för Linux med flera skyddsnivåer. Den Malware-skanner undersöker filer för att upptäcka känt eller misstänkt innehåll. Brandväggar samt IDS/IPS övervakar och begränsar misstänkt nätverksaktivitet, medan en webbapplikationsbrandvägg, förkortat WAF, utvärderar HTTP-förfrågningar före applikationen utifrån fastställda regler. Reputationskontroller ger ytterligare indikationer för klassificering av källor och aktiviteter.

Denna uppdelning är avgörande för webbhotellsoperatörer, eftersom skikten träder i kraft på olika ställen. En HTTP-attack mot en känd sårbarhet kan stoppas av WAF innan WordPress, Joomla eller Magento hinner bearbeta begäran. En skadlig uppladdning blir däremot relevant vid filkontrollen. Om en PHP-webshell körs kan Proaktivt försvar hantera misstänkt beteende under PHP-körningen; det är dock ingen retroaktiv analys av hela händelsen.

Modellen heter Flerlagersförsvar: En enskild säkerhetsbrist eller ett förbisedd fynd ska inte ensamt avgöra säkerheten för ett kundkonto. Malware-detektering kan avslöja befintlig skadlig kod, men den förhindrar inte nödvändigtvis den ursprungliga exploiten. På samma sätt kan en WAF blockera en attack utan att rensa bort redan lagrade filer eller manipulerat databasinnehåll.

Ingen av dessa nivåer ersätter grundläggande driftsuppgifter. CMS-kärnan, plugins, teman och tillägg behöver säkerhetsuppdateringar i rätt tid; restriktiva filbehörigheter och separata inloggningsuppgifter begränsar konsekvenserna av ett komprometterat konto. Kontrollerade säkerhetskopior möjliggör återställning, och om ett intrång upptäcks är det först en incidentanalys som klargör intrångsvägen, omfattningen och eventuell persistens. Imunify360 ger därför varnings- och identifieringssignaler, men inte ett fullständigt bevis på att omgivningen är säker.

Skillnaden mellan Imunify360, ImunifyAV och ImunifyAV+

Funktionslistorna måste kopplas till respektive produkt som används. Imunify360 är den mer omfattande säkerhetslösningen för servrar; ImunifyAV och ImunifyAV+ är separata produkter med funktioner som rör skadlig programvara. Den som likställer dessa namn kan till exempel förväxla en befintlig skanningsfunktion med brandväggsskydd, realtidsskydd eller PHP-skydd och därmed drar felaktiga slutsatser om en hanterad server eller en återförsäljarserver.

Det är särskilt viktigt att notera att realtidsskanning och proaktivt skydd, enligt tillverkarens dokumentation, inte finns tillgängliga i ImunifyAV respektive ImunifyAV+ på samma sätt som i Imunify360. Realtidsskanning kan snabbt upptäcka nya eller ändrade filer; Proactive Defense betraktar PHP-körning som en egen ingreppspunkt. Båda funktionerna kompletterar schemalagda filskanningar, men gör dem varken överflödiga och ersätter inte heller underhållet av applikationerna.

Även WordPress-tillägget Imunify Security Plugin är inte en fristående ersättning för serveragenten. Det hanteras av Imunify-agenten och distribueras inte via WordPress.org-katalogen. I WordPress-backend kan den ge tillgång till information om skanningar och skydd; vilka funktioner som visas beror dock på vilken Imunify-produkt som används och vilka versioner av agenten och tillägget som krävs i respektive fall.

För driftsdokumentationen rekommenderas därför en tydlig inventering: produktvariant, installerad agentversion, hostingpanel och aktiverade skyddsmoduler bör alla ingå i en ändringsdokumentation. En WordPress-administratör kan då klassificera meddelanden i backend utan att anta att pluginet styr brandväggsregler eller skyddar andra användarkonton på servern. Den serversidiga säkerhetsarkitekturen förblir avgörande.

Vad upptäckter av skadlig programvara egentligen säger oss

Bakgrunds- och on-demand-skanningar visar fynd i administrationsgränssnittet tillsammans med tidpunkt, filväg och orsak till upptäckten. Dessa uppgifter utgör en utgångspunkt för prioriteringen: filvägen kopplar ett fynd till ett kundkonto och en applikation, medan tidpunkten underlättar jämförelsen med distributioner, uppladdningar eller misstänkta loggposter. De ersätter dock inte en granskning av det konkreta innehållet och hur det har uppkommit.

För prioriteringen är typen av upptäckt viktig. Skadlig kod som smugits in i en i övrigt legitim fil talar ofta för att man bör undersöka filens ursprung, dess ändringar och ytterligare manipulationer inom samma konto. En fil som identifieras som skadlig i sig kan däremot tyda på en lagrad webshell, en dropper eller ett oönskat administrationsverktyg. Båda fallen kräver sammanhang snarare än automatiska slutsatser.

Ett fynd bevisar varken att varje fil i kontot har komprometterats, och det ger inte heller automatiskt någon bild av omfattningen av ett intrång. Omvänt innebär en skanning utan fynd inte att systemet är helt oskadat: nya typer av exploateringar, dold kod eller persistens utanför det skannade området kan kräva ytterligare undersökning. Inte heller är avsaknaden av WAF- eller skannerupptäckt ett bevis på att en attack inte har ägt rum.

Om skannern till exempel upptäcker en PHP-fil i ett WordPress-plugin bör webbplatsansvarig först spara sökhistoriken och sökvägen och jämföra filen med en pålitlig källa från tillverkaren eller en verifierad säkerhetskopia. Därefter bör pluginets version, administratörer, inloggningsuppgifter och eventuella bakdörrar kontrolleras. För den organisatoriska integreringen av flera WordPress-projekt är anvisningarna om Säkerhetskrav för Blogger-hosting, men ersätter inte fallspecifik kriminalteknik.

Skanningsmetoder, förutsättningar och räckvidd

Imunify360:s regelbundna filskanningar kontrollerar lagrade filer i webbhotellets filbestånd. De lämpar sig både för återkommande bakgrundskörningar och för en riktad kontroll efter en anmälan från övervakningen eller supporten. Resultatet avser dock endast den granskade filbeståndet: innehåll i en databas, en attack under en HTTP-förfrågan eller en åtkomst som redan har missbrukats kräver kompletterande kontroller och ytterligare skyddslager.

Der Realtidsskanning utvidgar denna kontroll till vissa överföringsvägar. För skanning av HTTP- och HTTPS-uppladdningar anger dokumentationen ModSecurity som en förutsättning; FTP-uppladdningar kräver Pure-FTPd. Om dessa tjänster är aktiva och korrekt konfigurerade måste därför kontrolleras för varje enskild server. Funktionen aktiveras inte automatiskt för alla uppladdningskanaler enbart genom installation av agenten.

Arkivkontrollen ingår också i skanningsomfånget. Enligt dokumentationen skannas ZIP-arkiv som standard sedan Imunify360 6.2. Detta är särskilt användbart för plugin-paket, säkerhetskopieringsarkiv eller uppladdade tillägg, men säger ingenting om huruvida ett program senare packar upp arkivet på ett osäkert sätt eller om dess innehåll är tekniskt tillåtet.

Der Skanner för skadlig programvara-databas (MDS) kompletterar filskanningar när skadlig kod har placerats i exempelvis inlägg, inställningar eller widgetinnehåll i ett CMS. Det dokumenterade stödet är begränsat till WordPress, Joomla och Magento 2. För egna applikationer, avvikande databasstrukturer eller andra webbutikssystem kan ingen fullständig databastäckning utgå från detta.

Planera RapidScan och databaskontroller

RapidScan förändrar arbetsflödet för upprepade kontroller, inte själva syftet med en skadlig kod-skanning. Inunify360 lagrar därför filmetadata och hashvärden lokalt och jämför hashvärdena med en molnbaserad databas. Vid senare genomgångar kan den lokala analysen koncentreras på filer som har ändrats eller som fortfarande är okända.

Den första genomgången kräver först en vanlig kontroll av filbeståndet. Tillverkaren anger att efterföljande skanningar kan bli fem till tjugo gånger snabbare. Detta intervall är en situationsberoende uppgift från tillverkaren, inte ett bindande löfte för varje server: filbeståndets storlek och sammansättning, ändringsfrekvens, tillgänglig I/O-kapacitet och nätverksförhållanden påverkar resultatet.

För planeringen innebär detta att en server med många oförändrade webbfiler kan RapidScan ger större fördelar än ett konto som kontinuerligt genererar uppladdningar, cacheminnen eller loggfiler. Mät därför inte bara den totala körtiden, utan dokumentera även berörda sökvägar, filomsättning och I/O-väntetid innan du gör ändringar. På så sätt kan skanningsfönster och undantag fastställas utifrån konkreta orsaker istället för antaganden.

Om WordPress-inlägg har manipulerats eller om skript har smugits in i inställningarna räcker det kanske inte med en ren filskanning. MDS kan först köras i icke-ingripande läge för WordPress-databaser som stöds --scan kontrollera. Detta steg medför inga ändringar av data och skapar en grund för att utvärdera fyndplatser, konsekvenser för webbplatsen och möjligheten till återställning innan ett beslut fattas.

Rensning eller återställning innebär däremot ingrepp i produktivt innehåll. Innan du påbörjar detta behöver du en aktuell, kontrollerad säkerhetskopia, ett godkännande från teknikavdelningen för den berörda webbplatsen samt en återgångsplan för det fall att legitimt innehåll skulle ändras. Vid många separata kundprojekt är det bra med en tydlig innehållsseparering, såsom den som även används vid Hosting för flera domäner Det viktiga är att den avgränsar ansvarsområdena och underlättar tilldelningen av fynd.

MDS är inte en ersättning för en fullständig incidentanalys. Återkommande skadlig kod i databasen kan tyda på ett sårbart plugin, komprometterade inloggningsuppgifter eller en bakdörr i en fil. När sådan kod upptäcks bör man därför, utöver databasens innehåll, även undersöka CMS, tillägg, användarkonton och varifrån skrivningen härstammar.

WordPress-integration och kontrollerade WAF-uppdateringar

WordPress-tillägget Imunify Security Plugin hanteras av Imunify-agenten på servern och distribueras inte via WordPress.org-katalogen. Den kan visa statusinformation för WordPress-administratörer och, beroende på vilken Imunify-produkt som används, ytterligare säkerhetsfunktioner i backend. Därmed fungerar den som ett gränssnitt och ett komplement, men inte som en ersättning för de serversidiga skannings- och skyddsmekanismerna.

För basfunktionen anger dokumentationen åtminstone Imunify360 8.4.1 på serversidan. Funktioner som WAF-integration eller AI Bot Management utvecklas separat och är knutna till specifika agent- och plugin-versioner. Kontrollera därför den konkreta versionskombinationen innan en utrullning, istället för att dra slutsatser om en viss skyddsfunktion enbart utifrån att plugin-programmet finns tillgängligt.

Även WAF bör drivas som en egen nivå. Från och med imunify360-firewall 8.6.0 Det finns en dokumenterad procedur för att inaktivera automatiska uppdateringar av ModSecurity-regler, visa en lista över tillgängliga regelversioner och välja en specifik version. Detta gör det möjligt för webbhotelloperatörer att på ett kontrollerat sätt planera regeländringar och, vid behov, byta till en känd version.

Ett lämpligt tillvägagångssätt är att först införa en ny regelversion på en staging-server med representativa WordPress-sidor, butikskampanjer och uppladdningar. Först när inga relevanta felaktiga blockeringar eller funktionsproblem kan konstateras sker en stegvis övergång till produktionsmiljön. Versionshanteringen avser här ModSecurity-regler, inte generella skadlig kod-signaturer, hela agenten eller andra Imunify-komponenter.

Kontrollerade Uppdateringar av WAF-regler De förhindrar inte alla störningar, men skapar tydliga ansvarsområden: Vem granskar ändringar, vilka applikationer används som testfall och när görs en återställning? Dessa frågor hör hemma i driftsprocessen. Det är fortfarande nödvändigt med snabba uppdateringar av CMS och tillägg, restriktiva behörigheter samt testade säkerhetskopior, eftersom ingen WAF åtgärdar kända sårbarheter i installerad programvara.

Kontrollera och hantera upptäckta skadliga program på ett säkert sätt

Ett fynd av skadlig programvara är en undersökningsprocess, inte automatiskt en instruktion om borttagning. Kontrollera först upptäcktshistoriken, tidpunkten, den fullständiga sökvägen och orsaken till upptäckten i gränssnittet. Dessa uppgifter hjälper dig att avgöra om filen tillhör ett plugin, ett tema, en uppladdningskatalog eller en egenutvecklad applikation, samt om samma fynd har uppstått tidigare.

Jämför en misstänkt PHP-fil med en pålitlig källa från tillverkaren av samma version eller med en verifierad säkerhetskopia. När det gäller standardkomponenter är en noggrann jämförelse oftast mer meningsfull än en isolerad granskning av enskilda, eventuellt dolda kodrader. Säkra fyndet och tillhörande loggar före varje ändring, så att en senare intrångsväg fortfarande kan spåras.

Den egentliga orsaksanalysen omfattar mer än den rapporterade vägen: Uppdatera berörda versioner av CMS, plugins och teman, kontrollera användarkonton och byt inloggningsuppgifter vid välgrundad misstanke. Sök dessutom efter ytterligare webshells, okända administratörer och misstänkta schemalagda uppgifter. Att en fil har tagits bort utesluter inte att angriparen har lämnat kvar en andra åtkomstväg.

En databasupptäckt kräver särskild försiktighet, eftersom korrigerande åtgärder kan ändra innehåll eller inställningar. En genomsökning är i första hand en kontroll; rensning eller återställning förutsätter en tillgänglig säkerhetskopia, ett godkännande från en expert samt en återhämtningsplan. Malware Database Scanner stöder endast de dokumenterade databasfallen för WordPress, Joomla och Magento 2 och är inte avsedd för en allmän kontroll av godtyckliga applikationsscheman.

Om Adminer upptäcks kan verktyget vara legitimt installerat, men är ändå ett förståeligt fynd på grund av dess funktionsomfång som kan utnyttjas för missbruk. I stället för att inaktivera en detekteringskategori globalt bör du kontrollera behovet, integriteten och åtkomstskyddet för den specifika filen. Om ett undantag är oundvikligt begränsar ett snävt undantag för sökvägar säkerhetsluckan bättre än en deaktivering av detekteringen på kontonivå eller servernivå.

Undersöka belastning, falska larm och uthållighet

Om CPU-belastningen eller I/O-väntetiden ökar bör uteslutning inte vara den första åtgärden. Registrera först skanningshändelser, berörda sökvägar, förändringshastigheter, aktiva processer och belastningens tidsperiod. Först den tidsmässiga korrelationen visar om realtidsskanning kan vara inblandad eller om exempelvis en säkerhetskopiering, en import, felaktiga applikationer eller en annan tjänst belastar resurserna.

Loggfiler som beskrivs ofta kan utlösa upprepade skanningsaktiviteter och därmed utgöra en möjlig orsak till ytterligare belastning. Ett dokumenterat supportärende behandlar detta mönster för WordPress-loggfiler, men bevisar inte någon allmän orsak-verkan-samband för varje överbelastad server. Kontrollera därför specifikt filvägar och skrivfrekvenser, istället för att i förebyggande syfte ta bort hela kundkataloger från Malware-skanner att undanta.

Undantag måste ha ett noggrant avgränsat syfte, en ansvarig person och en regelbunden granskning. För en legitimt skapad, mycket aktiv sökväg kan ett begränsat undantag vara motiverat efter en analys. Det får dock inte obemärkt utvidgas till uppladdnings- eller applikationskataloger där angripare skulle kunna placera eller ändra filer.

Återkommande fynd efter en rensning talar för en undersökning av Uthållighet istället för att bara radera dem. Förutom filer och databaser bör granskningen även omfatta cron-jobb, okända administratörskonton, inloggningsuppgifter, webbserverloggar och pågående processer. Särskilt schemalagda uppgifter kan ladda ner skadlig kod på nytt eller ersätta en borttagen webshell.

Sedan version 6.10 dokumenterar Imunify360 en genomsökning av system- och användar-crontabs som en experimentell funktion som är inaktiverad som standard. Detta utökar granskningsgränssnittet, men ersätter inte en manuell utvärdering av ett misstänkt jobb. Innan du aktiverar funktionen bör du kontrollera belastning, kompatibilitet och effekterna på din egen driftsmiljö; detta innebär inte att funktionen ska aktiveras generellt för alla hostingmiljöer.

Besluta om drift, migrering och införande

För en liten server med få webbplatser kan schemalagda bakgrundsskanningar, tydliga aviseringar och manuell godkännande av åtgärder vara tillräckligt. I återförsäljar- och delad hosting-miljöer ökar däremot kraven på Eskaleringsrutiner: Vem utvärderar anmälningar, vem kontaktar kunderna, vem får bevilja undantag och när begränsas ett konto? Dokumenterade ansvarsområden förhindrar att korrigerande åtgärder eller säkerhetsbrister hamnar i ett tomrum mellan supporten och administrationen.

Säkerhet i realtid, skanningsintervall och aviseringar måste anpassas efter förändringstakten och serverns resurser. Många oberoende kundkonton drar nytta av konsekventa rutiner och spårbar loggning. Ett enskilt, affärskritiskt projekt kräver ofta dessutom en samordnad underhålls- och godkännandeprocess. Grundläggande skyddsåtgärder som uppdateringar, minimala behörigheter och testade säkerhetskopior förblir oavsett detta nödvändiga.Kriterier för att välja ett lämpligt webbhotell

Produktionsrepositoriet och testinstallationerna måste hållas strikt åtskilda. Tillverkaren lanserar stabila versioner stegvis i produktionskanalen och anger en tidsram på upp till cirka två veckor för detta. En funktion som endast finns i testrepositoriet eller efter en installation med --beta är synligt, anses därför inte automatiskt vara allmänt tillgängligt på ett stabilt sätt.

En kontrollerad Utrullning börjar med versionsregistrering och en representativ staging- eller pilotserver. Efter uppdateringen kontrollerar du agentstatus, pakethantering, misstänkta loggar och de funktioner som är viktiga för kunderna. Först när allt har gått smidigt följer den stegvisa utrullningen. Detta eliminerar inte alla risker, men gör avvikelser synliga tidigare och underlättar en målinriktad åtgärd.

Den frivilliga övergången till Patchman är ett driftsbeslut, inte en automatisk modernisering. Efter migreringen går det inte längre att återställa filer från den tidigare Patchman-karantänen; enligt dokumentationen skapar Imunify säkerhetskopior av rensade filer. Innan en övergång bör operatörerna därför på ett bindande sätt klargöra lagring, återställningsmetoder, kundkommunikation och ansvarsfördelning.

Ett konkret uppdateringsproblem med imunify-common 1.3.21-1 på CloudLinux 8 med en Berkeley-DB-baserad RPM-databas åtgärdades enligt tillverkaren från och med version 1.3.22-2. Detta innebär inte något generellt argument mot uppdateringar. Det understryker dock varför underhållsfönster, dokumenterade versioner och efterkontroller av pakethanteringen är en del av en professionell uppdateringsprocess.