NordVPN
Krypterar internetuppkopplingen för anställda som jobbar på distans eller öppet wifi, så att inloggningar och kunddata inte exponeras i onödan.
Passar: Företag där någon loggar in på adminpaneler, e-post eller FTP utanför kontoret.
Säkerhet & GDPR
Malware-skanning av hemsida: när larmet måste följas upp
Ett malware-larm i skanningsverktyget säger sällan hela sanningen på egen hand. Här är hur du tolkar larmet, isolerar sajten och går vidare med sanering utan att stanna vid en falsk känsla av att allt redan är löst.
Ett larm från en malware-skanning, oavsett om det kommer från webbhotellet, ett säkerhetstillägg eller en extern tjänst, är en signal att utreda, inte en färdig diagnos. Skanningsverktyg letar efter kända mönster: signaturer, ovanliga filändringar eller kod som liknar tidigare sett skadligt innehåll. Det gör dem bra på att fånga upp mycket av det vanligaste, men de missar sådant som inte matchar ett känt mönster, till exempel en specialskriven bakdörr eller en manipulerad fil som är gjord för att se ut som originalet. Den här sidan går igenom hur du skiljer ett falsklarm från ett verkligt fynd, hur du isolerar sajten medan du utreder, och varför en enda ren skanning efteråt inte är samma sak som att problemet är löst.
Tolka larmet: falsklarm eller verkligt fynd
Börja med att läsa exakt vad larmet pekar ut: vilken fil, vilken kodrad eller vilket beteende som flaggats, och när det upptäcktes. Ett larm som pekar på en specifik, nyligen ändrad fil i ett tema eller tillägg är mer sannolikt verkligt än ett generiskt varningsmeddelande utan filväg. Falsklarm förekommer, till exempel när ett legitimt tillägg skriver kod på ett sätt som liknar kända angreppsmönster, eller när en gammal signaturdatabas flaggar ett numera ofarligt skript. Utred ändå alltid vidare innan du avfärdar larmet: jämför den flaggade filen mot en känd ren version om en sådan finns, och kontrollera om filen ändrats vid en tidpunkt som inte stämmer med ditt eget publiceringsarbete. Ett larm ska tas på allvar tills du kan visa motsatsen, inte avfärdas för att det känns osannolikt.
Det är också värt att skilja på vilken typ av kontroll som gett larmet, eftersom de fångar olika saker. En extern URL-skanning, av det slag som beskrivs i VirusTotals dokumentation för att skanna en URL, testar hur sajten ser ut utifrån och kan fånga kända skadliga mönster i det som visas för en besökare. En filintegritetskontroll jämför istället filerna på servern mot en känd ren version och slår larm vid oväntade ändringar, medan en fullständig genomgång på serversidan går igenom kod, databas och behörigheter för att hitta sådant de andra två metoderna kan missa. De tre kompletterar varandra snarare än att ersätta varandra, och ett larm från bara en av dem är inte samma sak som en fullständig utredning.
Isolera sajten innan du gör något annat
Om skanningen visar tecken på att skadlig kod aktivt sprids till besökare, till exempel omdirigeringar, nedladdningar som startar automatiskt eller spam som skickas ut via sajten, är nästa steg att begränsa skadan innan du utreder klart. Be webbhotellet ta sajten offline tillfälligt eller spärra den, snarare än att låta den vara nåbar medan du letar efter orsaken. Rör inte filer eller loggar mer än nödvändigt i det här skedet: dokumentera istället vad skanningen visade, när larmet kom och vilka filer som pekats ut, så att du har ett underlag att gå vidare med. Byt samtidigt lösenord till CMS, webbhotellskonto och FTP som en försiktighetsåtgärd, eftersom skadlig kod ofta kommer in via en läckt eller återanvänd inloggning snarare än en teknisk sårbarhet i sig.
Sanering: från fynd till faktiskt ren sajt
Med sajten isolerad handlar nästa fas om att gå från ett enskilt fynd till en faktiskt sanerad sajt. Ta reda på hur koden kom in innan du bara tar bort den flaggade filen, annars riskerar du att sanera symptomet men lämna kvar ingången öppen för nästa angrepp. Jämför drabbade filer mot en känd ren källa, till exempel en tidigare säkerhetskopia från innan larmet, och kontrollera samtidigt att den säkerhetskopian faktiskt är ren och inte redan innehåller samma problem. Uppdatera CMS, teman och tillägg till senaste version som en del av saneringen, eftersom en förlegad komponent ofta är just det som gav angriparen en väg in – vår systersajts guide till WordPress för småföretag går igenom plattformen mer i grunden. Är du osäker på om du hittat hela omfattningen, ta hjälp av webbhotellet eller en utvecklare med erfarenhet av sanering snarare än att gissa dig fram på egen hand.
Öppna inte sajten publikt igen förrän ni kan bekräfta tre saker: att den flaggade koden är borttagen och vägen in åtgärdad, att en ny skanning inte visar samma fynd, och att lösenord till CMS, webbhotell och FTP är bytta. Först då är återöppningen verifierad snarare än ett antagande som kan visa sig fel redan nästa dag.
| Risk | Åtgärd | Kontrollbevis | Källa |
|---|---|---|---|
| Larmet avfärdas utan utredning | Läs vilken fil och vilket beteende som flaggats innan du bedömer om det är verkligt | Dokumenterad tidpunkt och filväg för larmet | IMY |
| Sajten sprider skadlig kod vidare medan den utreds | Be webbhotellet ta sajten offline eller spärra den tillfälligt | Bekräftelse från webbhotellet om avstängning | NCSC |
| Samma sårbarhet återställs från en infekterad backup | Kontrollera att säkerhetskopian är ren innan den läggs tillbaka | Verifierad, ren återställningspunkt | WordPress.org |
| Personuppgifter kan ha exponerats av intrånget | Bedöm risken direkt och anmäl till IMY inom 72 timmar om det krävs | Tidsstämplad riskbedömning | IMY |
| Ingen vet om händelsen ska rapporteras vidare | Överväg frivillig rapportering till CERT-SE i det akuta skedet | Skickad eller övervägd rapport, dokumenterad | NCSC / CERT-SE |
Efter saneringen: undvik falsk trygghet
En ren skanning efter saneringen är ett bra tecken, men det är inte samma sak som en garanti. Skydd mot skadlig kod bör enligt Integritetsskyddsmyndigheten (IMY) kombinera förebyggande åtgärder, upptäckt och åtgärder när skadlig kod misstänks, vilket betyder att skanningen bara är en del av rutinen, inte hela rutinen. Kör därför en ny skanning några dagar senare för att se om något dyker upp igen, och håll ett extra öga på filändringar och inloggningar under de närmaste veckorna. Skriv samtidigt ihop en kort tidslinje över vad som hände, vad som gjordes och vem som informerades, så finns underlaget kvar om frågan kommer upp igen, till exempel från en kund eller en myndighet. Uppdateringar, begränsade behörigheter och rimliga filrättigheter är enligt WordPress.org grundstenar i den löpande härdningen som gör att samma typ av larm blir mindre sannolikt nästa gång, snarare än en engångsinsats du gör och sedan glömmer. Vår systersajts grundgenomgång av webbplatssäkerhet går igenom den löpande härdningen mer i detalj.
En ren skanning bevisar inte att sajten är säker, den visar bara att inget känt mönster hittades just då. Fortsätt kontrollera filändringar, inloggningar och uppdateringar en tid efter saneringen istället för att betrakta larmet som avslutat samma dag det försvinner.
Vanliga frågor
Är ett skanningslarm alltid ett tecken på verklig skadlig kod?
Nej, ett larm kan bero på ett falsklarm, till exempel ett tillägg som skriver ovanlig kod eller ett skript som liknar kända angreppsmönster utan att vara skadligt. Utred alltid larmet innan du drar slutsatsen att sajten är komprometterad, men behandla det som verkligt tills motsatsen är visad.
Räcker det med en skanning för att veta att sajten är säker igen?
Nej. Skanning är ett komplement till upptäckt, inte ett bevis på att allt är säkert. Den fångar kända mönster men missar bakdörrar eller manipulerade filer som inte matchar någon signatur, så en ren skanning ska följas av manuell kontroll innan du litar på resultatet.
Ska jag ta bort filerna med en gång larmet kommer?
Nej, radera inte filer eller loggar innan du dokumenterat vad skanningen visar och när larmet kom. Isolera sajten först så att skadan inte sprids vidare, men bevara spåren så att felkällan går att spåra och åtgärda på riktigt.
Behöver jag anmäla larmet till någon myndighet?
Bara om utredningen visar att personuppgifter kan ha exponerats och det inte är osannolikt att det medför risk för de registrerades rättigheter och friheter. Då ska incidenten anmälas till IMY inom 72 timmar från att du fick vetskap om den. Är du osäker, dokumentera bedömningen även om du landar i att ingen anmälan krävs.
Kan CERT-SE hjälpa till vid ett malware-larm på en liten sajt?
Ja, CERT-SE ger stöd vid pågående eller redan inträffade it-säkerhetsincidenter, och en frivillig rapportering dit kan vara relevant även om ditt företag inte har någon särskild rapporteringsplikt sedan tidigare.
