Cryptolockers i Sverige 2019

För några år sedan ringde det ibland kunder och hade den där speciella tonen på rösten som hintar om att något allvarligt har hänt. På den tiden förutsatte vi nästan att orsaken berodde på en cryptolocker av något slag.

Majoriteten av de kunder som drabbades kunde vi snabbt hjälpa genom att återställa data från snapshots. I resten av fallen fick vi återställa från backuper eller kanske replikerat data. Men vi hade aldrig en kund som drabbades av en dataförlust och tvingades betala lösensumman.
Nu har tiden gått och samtalen angående cryptolockers har minskat rejält. Både säkerhetsprodukterna och vi människor har anpassat oss till det hotet.

Häromdagen fick vi ändå ett nytt samtal gällande cryptolockers och denna gång var det illa, riktigt illa. Kunden i fråga hade upptäckt att ett konto var inloggat på servrarna som inte ska vara inloggat, samt att alla filer var konstiga, alltså krypterade.
I det här fallet fanns inga SAN snapshots. Replikering av virtuella maskiner då? Ja, men de servrar som var drabbade hade inte klassificerats och konfigurerats för replikering. Men det är ju lugnt, alla har ju backup? Ja visst, men olyckligtvis hade backupservern en utdelad katalog via vilken smittan spred sig. Det ledde till att backuperna var obrukbara.
Efter en hel del arbete stod vi inför faktum att enda utvägen var att betala den begärda lösensumman för att få backupservern återställd och därefter kunna återställa data från övriga servrar som drabbats.

Med anledning av den senaste upplevelsen där allt sket sig har jag sammanfattat ett par lärdomar som jag vill dela med mig av. Vissa saker är kanske självklarheter för somliga men jag hoppas att alla hittar något nytt:

  • Låt inte någon server vara exponerad på internet via RDP och se verkligen till att du inte använder dåliga lösenord. I dag verkar den vanligaste attackvektorn för cryptolockers vara just brute force attacker mot kända konton via RDP.
  • Om du har möjlighet inaktivera SMB1 protokollet och inventera dina utdelade mappar. Behöver du verkligen ha det där restore$ sharet på backup-servern tillgängligt hela tiden?
  • Överväg om din backupserver verkligen ska vara medlem i ditt AD. Detta för att undvika att ett kompromissat konto kan manipulera din backupserver. Det finns andra goda effekter av detta också som att din backupserver kanske är lite gladare även om hela ditt AD är nere.
  • Utnyttja snapshotteknik om du har det i ditt lagringssystem, detta är en oerhört effektiv metod för att snabbt kunna återställa stora datamängder. För hur snabbt går det egentligen för dig att återställa 10 servrar från backup? Har du inte tillgång till snapshotteknik kanske du ska byta lagringssystem?
  • Om du replikerar data eller virtuella maskiner mellan flera datacenter så fundera igenom vilka maskiner som omfattas av detta. Normalt sett väljer man kanske bara det som verkligen är affärskritiskt eftersom en sekundär site driver kostnader utan att generera någon direkt nytta. En stor fördel med replikerade virtuella maskiner är att dess kopior är avstängda och bortkopplade från nätverket. Vilket är ett av de bästa skydden mot smittor. Så även om du inte anpassar din sekundära site för att kunna köra alla system bör du överväga att kunna lagra en kopia av allt data.
Backup till molnet och katastrofsäkring (DRaaS) som tjänst med Veeam Cloud Connect

Backup till molnet och katastrofsäkring (DRaaS) som tjänst med Veeam Cloud Connect

Att ha en kopia av sitt data offsite blir allt viktigare i takt med att cyberattacker i form av ransomware ökar. Risken att drabbas blir allt högre och alla kan råka illa ut oavsett storlek på företag och resurser för att skydda sig mot en attack.
Är olyckan framme så är oftast enda räddningen att kunna ladda en kopia av sitt data som inte är smittad.

Med Veeam Cloud Connect kan man enkelt få en backup av data på annan plats. Man kan också ha en kopia av viktiga maskiner (virtuella och fysiska) och applikationer vilande för att snabbt kunna flytta driften av de mest kritiska systemen till molnet. Backupen krypteras innan den skickas till molnet. VPN-kryptering behövs inte utan Cloud Connect erbjuder en förkonfigurerad SSL-tunnel med WAN acceleration. Därefter kan man välja om datat skall lagras krypterat eller ej. Återställningstid för en virtuell maskin är i snitt endast 15 minuter. Du kan själv nå din backup, se status och vid behov återställa via Veeams kontrollpanel.

Parera erbjuder i egenskap av  Veeam Cloud & Service Provider (VCSP) i första hand lagring av datat i något av våra rack hos CONAPTO (tidigare SunGard) men vi kan även använda oss av molntjänsterna från Amazon AWS.

 

Genom att fylla i dina uppgifter nedan anmäler du dig till Pareras nyhetsbrev. Vi kommer inte att lämna ut dina uppgifter till någon annan part och du har alltid möjligheten att avanmäla dig från nyhetsbrevet när du själv vill.