Imunify360 Malware Scanner: Funktioner, opdateringer og begrænsninger

Imunify360 som flerlags hosting-sikkerhed

Imunify360 er ikke blot et virusprogram, men en Linux-sikkerhedsløsning med flere beskyttelseslag. Den Malware-scanner undersøger filer for kendt eller mistænkeligt indhold. Firewall samt IDS/IPS overvåger og begrænser mistænkelig netværksaktivitet, mens en webapplikationsfirewall (WAF) vurderer HTTP-anmodninger før de når frem til applikationen på baggrund af regler. Reputationskontroller leverer yderligere signaler til klassificering af kilder og aktiviteter.

Denne opdeling er afgørende for hostingudbydere, fordi lagene træder i kraft på forskellige steder. Et HTTP-angreb på en kendt sårbarhed kan blive afværget af WAF'en, inden WordPress, Joomla eller Magento behandler anmodningen. En skadelig upload bliver derimod relevant ved filkontrollen. Hvis en PHP-webshell udføres, kan Proaktivt forsvar håndtere mistænkelig adfærd under PHP-udførelsen; det er dog ikke en retrospektiv analyse af hele hændelsen.

Modellen hedder Flerlagsforsvar: En enkelt sårbarhed eller et overset fund bør ikke alene være afgørende for sikkerheden på en kundekonto. Malware-detektering kan afsløre eksisterende skadelig kode, men den forhindrer ikke nødvendigvis det oprindelige angreb. Ligeledes kan en WAF blokere et angreb uden at rydde op i allerede gemte filer eller manipuleret databaseindhold.

Ingen af disse niveauer erstatter grundlæggende driftsopgaver. CMS-kernen, plugins, temaer og udvidelser kræver rettidige sikkerhedsopdateringer; restriktive filrettigheder og adskilte adgangsoplysninger begrænser konsekvenserne af en kompromitteret konto. Kontrollerede sikkerhedskopier muliggør gendannelse, og hvis der opdages et sikkerhedsbrud, er det først en hændelsesanalyse, der afklarer indtrængningsvejen, omfanget og eventuel vedvarende trussel. Imunify360 giver derfor advarsels- og detektionssignaler, men ikke et fuldstændigt bevis på, at omgivelserne er sikre.

Forskellen mellem Imunify360, ImunifyAV og ImunifyAV+

Funktionslister skal tilknyttes det pågældende produkt. Imunify360 er den mere omfattende sikkerhedsløsning til servere; ImunifyAV og ImunifyAV+ er separate produkter med funktioner til beskyttelse mod malware. Hvis man sætter disse navne på lige fod, kan man f.eks. forveksle en eksisterende scanningsfunktion med firewall-, realtids- eller PHP-beskyttelse og deraf udlede forkerte forventninger til en managed- eller reseller-server.

Det er især relevant, at realtidsscanning og proaktivt forsvar ifølge producentens dokumentation ikke er tilgængelige i ImunifyAV henholdsvis ImunifyAV+ på samme måde som i Imunify360. Realtidsscanning kan hurtigt registrere nye eller ændrede filer; Proactive Defense betragter PHP-udførelse som et særskilt indgrebspunkt. Begge funktioner supplerer planlagte filscanninger, men gør disse hverken overflødige eller erstatter vedligeholdelsen af applikationerne.

WordPress-udvidelsen, der kaldes Imunify Security Plugin, er heller ikke en selvstændig erstatning for serveragenten. Den administreres af Imunify-agenten og leveres ikke via WordPress.org-kataloget. I WordPress-backend kan den give adgang til oplysninger om scanning og beskyttelse; hvilke funktioner der vises, afhænger dog af det anvendte Imunify-produkt og de respektive krævede versioner af agenten og udvidelsen.

Til driftsdokumentationen anbefales det derfor at lave en overskuelig oversigt: Produktvariant, installeret agentversion, hostingpanel og aktiverede beskyttelsesmoduler hører alle sammen hjemme i en ændringsdokumentation. En WordPress-administrator kan derefter klassificere meddelelser i backend uden at antage, at pluginet styrer firewall-regler eller beskytter andre brugerkonti på serveren. Den serversidige sikkerhedsarkitektur forbliver afgørende.

Hvad fund af malware egentlig fortæller os

Baggrundsscanninger og on-demand-scanninger viser fundne resultater i administrationsgrænsefladen sammen med tidspunkt, filsti og årsag til påvisningen. Disse oplysninger danner udgangspunkt for prioriteringen: Filstien knytter et fund til en kundekonto og en applikation, mens tidspunktet hjælper med at sammenholde det med implementeringer, uploads eller mistænkelige logposter. De erstatter dog ikke en gennemgang af det konkrete indhold og dets oprindelse.

For prioriteringen er det vigtigt, hvilken type detektion der er tale om. Skadelig kode, der er indsat i en ellers legitim fil, taler ofte for, at man undersøger filens oprindelse, ændringer og yderligere manipulationer på den samme konto. En fil, der genkendes som skadelig i sig selv, kan derimod være tegn på en gemt webshell, en dropper eller et uønsket administrationsværktøj. Begge tilfælde kræver kontekst i stedet for automatiske konklusioner.

Et fund beviser hverken, at alle filer på kontoen er kompromitteret, eller at det automatisk angiver omfanget af et indbrud. Omvendt er en scanning uden fund ikke bevis på fuldstændig sikkerhed: Nye former for exploits, skjult kode eller persistens uden for det registrerede område kan kræve yderligere undersøgelse. Heller ikke manglende WAF- eller scannerdetektion er et bevis på, at der ikke har fundet et angreb sted.

Hvis scanneren f.eks. finder en PHP-fil i et WordPress-plugin, bør webstedsejeren først gemme fundhistorikken og stien og sammenligne filen med en pålidelig kilde fra producenten eller en verificeret sikkerhedskopi. Derefter skal plugin-versionen, administratorer, adgangsoplysninger og eventuelle bagdøre kontrolleres. Ved organisatorisk integration af flere WordPress-projekter kan vejledningen til Sikkerhedskrav til Blogger-hosting, men kan ikke erstatte en sagspecifik retsmedicinsk undersøgelse.

Scanningsmetoder, forudsætninger og rækkevidde

Imunify360’s regelmæssige filscanninger kontrollerer gemte filer i hostingbestanden. De egner sig både til tilbagevendende baggrundskørsler og til en målrettet kontrol efter en henvisning fra overvågning eller support. Resultatet vedrører dog kun den undersøgte filbestand: Indhold i en database, et angreb under en HTTP-anmodning eller en adgang, der allerede er blevet misbrugt, kræver supplerende kontroller og beskyttelseslag.

Der Realtidsscanning udvider denne kontrol til bestemte overførselsveje. Til scanning af HTTP- og HTTPS-uploads angiver dokumentationen ModSecurity som en forudsætning; FTP-uploads kræver Pure-FTPd. Det skal derfor kontrolleres for hver enkelt server, om disse tjenester er aktive og korrekt konfigureret. Funktionen er ikke automatisk tilgængelig for alle upload-kanaler alene ved installation af agenten.

Arkivkontrol indgår også i scanningsomfanget. Ifølge dokumentationen scannes ZIP-arkiver som standard fra og med Imunify360 6.2. Dette er især nyttigt i forbindelse med plugin-pakker, sikkerhedskopieringsarkiver eller uploadede udvidelser, men siger intet om, hvorvidt et program senere udpakker arkivet på en usikker måde, eller om indholdet er fagligt tilladt.

Der Scanner til malware-database (MDS) supplerer filscanninger, hvis der er indlejret skadelig kode i f.eks. indlæg, indstillinger eller widgetindhold i et CMS. Den dokumenterede understøttelse er begrænset til WordPress, Joomla og Magento 2. For egne applikationer, afvigende databasestrukturer eller andre webshopsystemer må der ikke udledes en fuldstændig databasedækning heraf.

Planlægning af RapidScan og databasekontroller

RapidScan ændrer forløbet af gentagne scanninger, ikke det grundlæggende formål med en malware-scanning. Imunify360 gemmer i den forbindelse filmetadata og hashværdier lokalt og sammenligner hashværdierne med en cloudbaseret database. Ved senere gennemløb kan den lokale analyse koncentreres om filer, der er ændret eller endnu ukendte.

Den første gennemkørsel kræver først en almindelig kontrol af filbestanden. Producenten angiver, at efterfølgende scanninger kan foregå fem til tyve gange hurtigere. Dette interval er en situationsafhængig angivelse fra producenten og ikke et bindende løfte for hver enkelt server: Filbestandens størrelse og sammensætning, ændringsfrekvens, tilgængelig I/O-ydeevne og netværksforhold påvirker resultatet.

For planlægningen betyder det: En server med mange uændrede webfiler kan af RapidScan giver større fordele end en konto, der løbende genererer uploads, cachefiler eller logfiler. Mål derfor ikke kun den samlede køretid, men dokumenter også de berørte stier, filomsætningen og I/O-ventetiden, inden du foretager ændringer. På den måde kan scanningsvinduer og undtagelser fastlægges på baggrund af konkrete årsager i stedet for antagelser.

I tilfælde af manipulerede WordPress-indlæg eller indsatte scripts i indstillingerne er en ren filscanning muligvis ikke tilstrækkelig. MDS kan for understøttede WordPress-databaser i første omgang køre i ikke-interventerende tilstand --scan Kontroller. Dette trin ændrer ikke på dataene og danner grundlag for at vurdere fundsteder, indvirkningen på hjemmesiden og muligheden for gendannelse, inden der træffes en beslutning.

Rensning eller gendannelse er derimod indgreb i produktivt indhold. Først skal du have en opdateret, kontrolleret sikkerhedskopi, en faglig godkendelse for det pågældende websted og en plan for, hvad der skal gøres, hvis legitimt indhold ændres. Ved mange separate kundeprojekter er det en fordel med en klar adskillelse af indhold, som det også er tilfældet hos Hosting på flere domæner Det vigtige er: Den afgrænser ansvarsområderne og gør det lettere at henføre fund.

MDS er ikke en erstatning for en fuldstændig analyse af hændelsen. Databaseskadekode, der dukker op igen, kan være tegn på et sårbart plugin, kompromitterede adgangsoplysninger eller en fil-backdoor. Når sådan en kode opdages, bør man derfor ud over databaseindholdet også undersøge CMS, udvidelser, brugerkonti og oprindelsen af skriveoperationen.

WordPress-integration og kontrollerede WAF-opdateringer

WordPress-udvidelsen, der kaldes Imunify Security Plugin, administreres af Imunify-agenten på serveren og leveres ikke via WordPress.org-kataloget. Den kan give WordPress-administratorer adgang til statusoplysninger og, afhængigt af det anvendte Imunify-produkt, yderligere sikkerhedsfunktioner i backend. Den fungerer dermed som en brugergrænseflade og et supplement, men er ikke en erstatning for de serversidige scannings- og beskyttelsesmekanismer.

For basisfunktionen angiver dokumentationen som minimum Imunify360 8.4.1 på serversiden. Funktioner som WAF-integration eller AI Bot Management er videreudviklet separat og er knyttet til de respektive angivne agent- og plugin-versioner. Kontroller derfor den konkrete versionskombination inden en udrulning, i stedet for at konkludere, at en bestemt beskyttelsesfunktion er til stede, blot fordi pluginet findes.

Også WAF bør drives som et separat lag. Fra imunify360-firewall 8.6.0 Der findes en dokumenteret fremgangsmåde til at deaktivere automatiske opdateringer af ModSecurity-regler, vise en liste over tilgængelige regelversioner og vælge en bestemt version. Dette giver hostingudbydere mulighed for at planlægge regelændringer på en kontrolleret måde og om nødvendigt skifte til en kendt version.

En fornuftig fremgangsmåde er først at indføre en ny regelversion på en staging-server med repræsentative WordPress-sider, kampagner i webshoppen og uploads. Først når der ikke kan konstateres relevante fejlblokeringer eller funktionsproblemer, følger den trinvise overførsel til produktionsmiljøet. Versionsstyringen vedrører her ModSecurity-regler, ikke generelle malware-signaturer, hele agenten eller andre Imunify-komponenter.

Kontrolleret Opdateringer af WAF-regler De forhindrer ikke alle fejl, men skaber klare ansvarsforhold: Hvem kontrollerer ændringer, hvilke applikationer fungerer som testtilfælde, og hvornår foretages der en tilbageførsel? Disse spørgsmål hører hjemme i driftsprocessen. Det er stadig nødvendigt med rettidige opdateringer af CMS og udvidelser, restriktive rettigheder samt testede sikkerhedskopier, da ingen WAF fjerner kendte sårbarheder i den installerede software.

Sikker kontrol og håndtering af fundne malware-programmer

Et fund af malware er en undersøgelsesproces og ikke automatisk en anvisning om sletning. Tjek først fundhistorikken, tidspunktet, den fulde sti og årsagen til detekteringen i brugergrænsefladen. Disse oplysninger hjælper med at afgøre, om filen hører til et plugin, et tema, et upload-katalog eller en individuelt udviklet applikation, og om det samme fund allerede er forekommet tidligere.

Sammenlign en mistænkelig PHP-fil med en pålidelig kilde fra producenten af samme version eller med en verificeret sikkerhedskopi. For standardkomponenter er en grundig ny sammenligning som regel mere sigende end en isoleret gennemgang af enkelte, muligvis forklædte kodelinjer. Sikr fundet og de tilhørende logfiler før enhver ændring, så en senere indtrængningsvej stadig kan spores.

Den egentlige årsagsanalyse omfatter mere end den rapporterede sti: Opdater de berørte CMS-, plugin- og temaversioner, kontroller brugerkonti, og skift adgangskoder, hvis der er begrundet mistanke. Søg desuden efter yderligere webshells, ukendte administratorer og mistænkelige planlagte opgaver. At en fil er blevet fjernet, udelukker ikke, at angriberen har efterladt en anden adgang.

Et fund i databasen kræver særlig tilbageholdenhed, da korrigerende indgreb kan ændre indhold eller indstillinger. En scanning er i første omgang en kontrol; oprydning eller gendannelse forudsætter en tilgængelig sikkerhedskopi, en faglig godkendelse og en beredskabsplan. Malware Database Scanner understøtter kun de dokumenterede databasetilfælde for WordPress, Joomla og Magento 2 og er ikke en generel kontrol af vilkårlige applikationsskemaer.

Hvis Adminer opdages, kan værktøjet være installeret på lovlig vis, men det er et forståeligt fund på grund af dets funktionsomfang, der kan misbruges. I stedet for at deaktivere en detekteringskategori globalt bør du vurdere behovet, integriteten og adgangsbeskyttelsen for den konkrete fil. Hvis en undtagelse er uundgåelig, begrænser en snæver sti-undtagelse sikkerhedshullet bedre end en deaktivering af detekteringen på konto- eller serverniveau.

Undersøgelse af belastning, falske alarmer og vedholdenhed

Hvis CPU-udnyttelsen eller I/O-ventetiden stiger, bør en udelukkelse ikke være den første foranstaltning. Registrer først scanningshændelser, berørte stier, ændringshastigheder, aktive processer og belastningsperioden. Først den tidsmæssige sammenhæng viser, om realtidsscanning kan være en faktor, eller om det f.eks. er en backup, en import, fejlbehæftede applikationer eller en anden tjeneste, der belaster ressourcerne.

Ofte beskrevne logfiler kan gentagne gange udløse scanningsaktivitet og dermed være en mulig årsag til ekstra belastning. En dokumenteret supportssag omhandler dette mønster for WordPress-logfiler, men beviser ikke en generel årsag-virkning-sammenhæng for alle overbelastede servere. Kontroller derfor konkret filstier og skrivefrekvenser i stedet for forebyggende at fjerne hele kundemapper fra Malware-scanner at udelade.

Undtagelser kræver et klart afgrænset formål, en ansvarlig person og en regelmæssig kontrol. For en legitimt genereret, meget aktiv sti kan en begrænset undtagelse efter en analyse være berettiget. Den må dog ikke ubemærket udvides til upload- eller applikationsmapper, hvor angribere kunne placere eller ændre filer.

Tilbagevendende fund efter en oprydning taler for en undersøgelse af Vedholdenhed i stedet for blot at slette dem. Ud over filer og databaser bør kontrollen også omfatte cron-jobs, ukendte administratorkonti, adgangsoplysninger, webserverlogfiler og kørende processer. Især planlagte opgaver kan downloade skadelig kode igen eller erstatte en fjernet webshell.

Imunify360 har siden version 6.10 dokumenteret en scanning af system- og bruger-crontabs som en eksperimentel funktion, der som standard er deaktiveret. Dette udvider kontrolgrænsefladen, men erstatter ikke en manuel vurdering af en mistænkelig opgave. Inden du aktiverer funktionen, skal du undersøge belastningen, kompatibiliteten og indvirkningen på din egen drift; dette betyder ikke, at funktionen skal aktiveres generelt for alle hostingmiljøer.

Drift, migrering og udrulning er afgørende

For en lille server med få hjemmesider kan planlagte baggrundsscanninger, overskuelige meddelelser og manuel godkendelse af foranstaltninger være tilstrækkeligt. I reseller- og shared hosting-miljøer stiger kravene derimod til Eskaleringsprocedurer: Hvem vurderer fund, hvem kontakter kunderne, hvem må godkende undtagelser, og hvornår bliver en konto begrænset? Dokumenterede ansvarsområder forhindrer, at korrigerende indgreb eller sikkerhedshuller bliver liggende mellem support og administration.

Beskyttelse i realtid, scanningsintervaller og underretninger skal være tilpasset ændringsfrekvensen og serverens ressourcer. Mange uafhængige kundekonti drager fordel af ensartede procedurer og sporbar logføring. Et enkelt, forretningskritisk projekt kræver ofte desuden en afstemt vedligeholdelses- og godkendelsesproces. Grundlæggende beskyttelsesforanstaltninger som opdateringer, minimale rettigheder og testede sikkerhedskopier er uafhængigt heraf stadig nødvendige.Kriterier for valg af et passende webhosting-tilbud

Produktionsrepositoriet og testinstallationerne skal holdes strengt adskilt. Producenten udruller stabile versioner gradvist i produktionskanalen og angiver en tidsramme på op til cirka to uger hertil. En funktion, der kun findes i testrepositoriet eller efter en installation med --beta Det, der er synligt, betragtes derfor ikke automatisk som generelt stabilt tilgængeligt.

En kontrolleret Udrulning begynder med versionsregistrering og en repræsentativ staging- eller pilotserver. Efter opdateringen tjekker du agentstatus, pakkehåndtering, mistænkelige logfiler og de funktioner, der er vigtige for kunderne. Først når alt forløber uden problemer, følger den trinvise udrulning. Det eliminerer ikke alle risici, men gør afvigelser synlige tidligere og letter en målrettet reaktion.

Den frivillige overgang til Patchman er en driftsbeslutning, ikke en automatisk modernisering. Efter migreringen kan filer ikke længere gendannes fra den tidligere Patchman-karantæne; ifølge dokumentationen opretter Imunify sikkerhedskopier af rensede filer. Inden en overgang bør operatører derfor på forhånd fastlægge regler for opbevaring, gendannelsesprocedurer, kundekommunikation og ansvarsfordeling.

Et konkret opdateringsproblem med imunify-common 1.3.21-1 på CloudLinux 8 med en Berkeley-DB-baseret RPM-database blev ifølge producenten rettet fra og med version 1.3.22-2. Dette er ikke et generelt argument imod opdateringer. Det understreger dog, hvorfor vedligeholdelsesvinduer, dokumenterede versioner og efterkontrol af pakkehåndteringen er en del af en professionel opdateringsproces.