Ransomware og Ubuntu Server?

[Dan Hansen]

Af ren nysgerrighed, hvis jeg har en Ubuntu Server med familiens file på (dokumenter, billeder, musik etc), vil den så være sikret mod ransomware? Uafhængig af hvad slags styresystem der bruges lokalt på computerne?

[AJenbo]

Tjo, det kunne man godt sige i en vis forstand, men jeg ville passe på med at udstede garantier for hvis en rigtig hacker får adgang til de rigtige ting er der jo næsten ingen grænse for hvad de kan gøre.

Det ville være klogt at have et backup af maskinen.

[zob]

Ransomware er ikke en trussel (uanset om du faktisk bliver befængt med det) hvis du har en backup og du er ligeglad med om andre også får dine filer at se. Pointen er jo at få dig til at betale for at få adgang til filerne igen og/eller forhindre at filerne bliver offentliggjort.
Hvis du har filer som ikke må havne i de forkerte hænder bør du sikre din server (du skriver ikke om server er eksponeret mod internettet eller kun kan tilgås fra LAN) og kryptere det drev filerne ligger på.
Hvis det er ligegyldigt for dig om andre får fingre i dine filer er problemet noget mindre. Her kræves vel kun en backup - sat lidt på spidsen.
Her går jeg ud fra at hackeren også kan tilgå filerne - ikke kun låse adgangen til dem. Det ved jeg faktisk ikke 100% om er en del af pointen i ransomware.

Styresystemet der bruges på klienterne er vel sagen underordnet (undtagelse: hvis du tænker at din server ikke behøver beskyttelse fordi den kun er eksponeret mod LAN, er det selvfølgelig vigtigt at klienter på LAN ikke efterlader en åben dør fra internettet til dit LAN).

Der er så mange "hvis'er" her at det ville kræve en noget mere detaljeret beskrivelse af dit setup (og viden om dine datas egnethed for offentliggørelse og backupstatus) for at kunne givet en bedre svar.

Egentlig var det jeg ville sige med denne lidt rodede besked bare at du bør forestille dig hvilken situation du skal være i for at du vil betale nogen for at du igen får adgang til dine filer. Hvis du ikke på noget måde kan forestille dig sådan en situation er ransomware vel ikke en trussel mod dig.

[lath]

Af ren nysgerrighed, hvis jeg har en Ubuntu Server med familiens file på (dokumenter, billeder, musik etc), vil den så være sikret mod ransomware? Uafhængig af hvad slags styresystem der bruges lokalt på computerne?

Idè: Brug et read-only filsystem til filer som du ikke ønsker skal kunne slettes eller ændres i, private billeder f.eks.. Du kan også kryptere dem, hvis du vil.

Du kunne - udover at lave backups, hvilket altid er en god ide - splitte et filsystem op i mindst 2 filsystemer. Et der read-write monteres, og et andet der et read-only monteres.
Ikke engang root (superbrugeren) kan skrive/slette/ændre i filer på et read-only filsystem. Først når filsystemet er genmonteret read-write kan superbrugeren skrive/slette/ændre på filer og mapper.
Formålet med et read-only filsystem er at der ikke ved et uheld (eller ransomware) kan ændres i filer.

Hvis ransomware f.eks. det får adgang til din desktop computer (det kunne være en Windows maskine idet at nogle har mere end et styresystem/en maskine), men ikke serveren, så vil alle anmodninger om at ændre noget som helst i read-only filsystemet på serveren fejle.

Den ændring er lidt omfattende at udføre:

1. Boot systemet op i en Live session (fordi filsystemerne så ikke er monteret)
2. starte gparted og formindske nuværende read-write partition
3. Oprette ny partition, og formattere den
4. Oprette en ny tom mappe som bliver monteringspunktet for din nye read-only partition.
5. I /etc/fstab indsætte en ny linie som auto mounter din nye partitions filsystem som et read-only filsystem (option ro). Hvis din init er systemd i stedet for upstart, så skal det muligvis ske et andet sted, og på en anden måde i en ny systemd unit fil.
6. Tilføje read-only filsystemet til de fildelings servere du bruger, f.eks. Samba - det skal ske i en konfigurationsfil, og fildelingsserverne skal næsten helt sikkert genstartes før ændringer træder i kraft.

En gang imellem gen-monterer du read-only filsystemet som et read-write filsystem og overfører filer og mapper fra read-write filsystemet til det der normalt er read-only filsystemet. Til slut genmonterer du read-only filsystem som read-only filsystem.

Ændre bruger og rettigheder i stedet for at bruge et read-only filsystem
En anden måske nemmere løsning er at ændre i rettigheder for filer og mapper, og evt flytte ejeren af en fil/mappe over til en anden nyoprettet bruger som kunne hedde: readonly, som ikke kan logge ind og få adgang til en shell, og ikke har en bruger mappe i /home.
Write bitten for group og other, skal så være: 0 (må ikke skrive/ændre/overskrive/slette).

/Lars

[AJenbo]

Ransomware fungere normal blot ved at låse brugerfladen ved Windows kan det ske for operativ systemet men for Mac og Linux har jeg kun set det hvor det låser browseren og ikke overlever en genstart. Fælles for dem er at de tekniske set ikke har låst eller gjort noget ved data. Man kunne installere Windows på ny og så være kørende igen, eller man kunne sætte disken i en anden maskine og så tilgå filerne (det kan også gøres med en live ubuntu disk).

[Dan Hansen]

Hmm - det lille jeg har set af ransomware har krypteret hele harddisker, og eneste udvej er at formatere harddisken, før man igen kan bruge computeren. Alle filer (dokumenter, billeder med videre) er krypteret og man kan ikke få tilgang overhovedet.

Lægger man så tilbage en tidligere backup uden at fjerne ransomwaren, så er den ligeså gal igen.

Nu ved jeg ikke rigtigt hvor stor faren er her i huset, da vi alle har vores egne filer separat på hver vores computer + backup, men planen er at sætte op en server med enkel fildeling (egne "directories" - eller hvad det nu hedder på dansk - og et fælles område) og da kan vel en potentiel "hacker" vel ikke uden videre komme til de andres områder på serveren hvis en af computerne skulle blive kompromitteret?

Jeg kan svært forestille mig at de virkelig dygtige gider at brænne så alt for meget krut af på vores computere - men den gængse "script-kid" der er ude efter nogle hurtige lommepenge måske er noget mere interesseret i at udnytte sikkerhetshul til disse ting ...

[lath]

Hmm - det lille jeg har set af ransomware har krypteret hele harddisker, og eneste udvej er at formatere harddisken, før man igen kan bruge computeren. Alle filer (dokumenter, billeder med videre) er krypteret og man kan ikke få tilgang overhovedet.

Lægger man så tilbage en tidligere backup uden at fjerne ransomwaren, så er den ligeså gal igen.

Nu ved jeg ikke rigtigt hvor stor faren er her i huset, da vi alle har vores egne filer separat på hver vores computer + backup, men planen er at sætte op en server med enkel fildeling (egne "directories" - eller hvad det nu hedder på dansk - og et fælles område) og da kan vel en potentiel "hacker" vel ikke uden videre komme til de andres områder på serveren hvis en af computerne skulle blive kompromitteret?

Jeg kan svært forestille mig at de virkelig dygtige gider at brænne så alt for meget krut af på vores computere - men den gængse "script-kid" der er ude efter nogle hurtige lommepenge måske er noget mere interesseret i at udnytte sikkerhetshul til disse ting ...

For fælles området kan du starte ud med at lave de her 2 ting:

1. Sæt sticky bit for fælles området: Filer og mapper kan kun slettes/ændres i af ejeren.
2. Sæt umask system-wide, så de rettigheder - rwx for brugeren, gruppen, og other(=alle andre) - sætes rigtigt, når filer og mapper oprettes.
   
   • Her en god artikel for at få mere at vide om umask:
     http://www.cyberciti.biz/tips/understanding-linux-unix-umask-value-usage.html
   • Bemærk at en umask-bit der er logisk 1 fortæller at den tilsvarende rettigheds-bit for filen/mappen skal sættes til logisk 0 - altså den rettighed bliver fjernet/ikke tillades.
   • Modsat er det med en umask-bit der er logisk 0, her er det en rettigheds-bit, der bliver tildelt/tilladt (sat til logisk 1).

Hvis nu det er meningen at filer og mapper på fællesområdet ikke sådan lige skal slettes igen, så kan du jo bare køre en række at/cron jobs meget ofte der:

1. Skifter ejeren ud til at være root (superbrugeren)
2. Skift gruppen ud til at være en som alle der må bruge fællesområdet er medlem af.
3. Sætter rettigheden til: 640 for filer, og 760 for mapper - bemærk at other-bits alle er nul, så der er nul adgang for en bruger, der ikke er ejeren (root), eller er medlem af fællesdrev-gruppen.

Du kan også lade root på serveren eje alle filer og mapper på fælles drevet, og så sætte other bits så man kun kan få en liste af filer fra en mappe, og kun læse fra en fil.
På den måde er det komplet umuligt at ændre noget via et netværksdrev, især hvis du lader netværks-server programmet kører som en upriviligeret bruger - der kun må bruge lave port numre.
Du kan tillade et program at bruge lave portnumre (portnumre < 1025).
Du skal bruge et program der hedder setcap, og rettigheden finder du i capabilities(7) :

Kode: Vælg alt

man 7 capabilities

Du skal sætte rettigheden på netværksserverens programfil med setcap.
Når du har gjort det, så kan du køre programmet, uden at server-programmet skal have alle root-rettigheder=alle rettigheder fra capabilities(7). Du kan derfor køre programmet under en uprivilegeret bruger, som ikke har en hjemmemappe, og ikke kan logge ind (= har /usr/sbin/nologin som shell i /etc/passwd). Du kan bruge den allerede eksisterende bruger nobody eller daemon, men det er smartest at bruge en separat bruger af sikkerhedsmæssige årsager.

Bemærk at når bare en eneste bit ændres i server-programmet, så mister programmet alle tildelte capabilities(7) rettigheder - det sker typisk ved en apt-get opgradering til en nyere version af programmet.
Af den årsag er det måske praktisk at sætte apt-get op til at køre manuel opgradering, og så lave et cron job der kører apt-get + en setcap kommando lige efter at apt-get muligvis/muligvis ikke har opgraderet netværksserveren.

Du kan osgå isolere programmet inde i en LXC (Linux container), hvor den uprivigerede bruger bliver til root brugeren inde i LXCen.
Det betyde at du kan køre root kommandoer inde i LXCen fra en terminal udenfor LXCen.
Du må ikke bruge sudo udenfor LXCen, da sudo på systemet der hoster LXCen jo tilhører root brugeren for bare-metal/VPS serveren.

Hvis du bliver forvirret over det her med at der kan være mange superbrugere, så er det fordi at Linux kernen understøtter noget der kaldes for namespaces - og ikke kun for brugere:

• Det gælder også procestræet - hvor der kan være mere end 1 init (=et start-program, der starter alle andre programmer). I det globale procestræ, som pstree kommandoen bruger, der kan man se alle programmer.
• monteringspunkter - som er de filsystemer - filer og mapper - et program kan "se"
• ... og meget mere

/Lars