Du bør checke fil-integriteten på din webserver

En bagdør i en php-fil behøver højst fylde et par linjer, og derfor er det en god idé løbende at tjekke fil-integriteten på webserveren.

Det kan være sin sag at være up-to-date med patches, også på webserveren. Blandt andet derfor kan det være en god idé at køre et automatisk integritetscheck, hvis nu nogen skulle have brugt et åbent sikkerhedshul til at pille ved filerne på serveren.

Faktisk går det slet ikke at lade være med at checke filerne på sådan en server, mener leder af televirksomheden Verizons risk-team Lorenz Kuhlee.

»På en webserver er det et must. Hvis du for eksempel har en php-baseret eCommerce webserver. Så har du med tusindvis af php-kodelinjer at gøre. En bagdør kan være på en eller to linjer,« siger han og fortsætter:

»En eller to linjer, og fra et forensic standpunkt, så er det ofte for omkostningstungt at gennemgå tusindvis af linjer for at finde en eller to linjer.«

Integritets-tjekket eller File Integrity Monitoring (FIM), som det kaldes, kan køres automatiseret med givne intervaller, hvor den ansvarlige modtager en mail, hvis noget ikke stemmer.

FIM kan foregå ved at beregne en kryptografisk checksum for hver enkelt fil. Hvis checksummen ændrer sig, betyder det i udgangspunktet, at indholdet af filen har ændret sig.

Og hvis ikke der umiddelbart er en gyldig forklaring på ændringen, så kan det være tegn på ubudne gæster på serveren.

Lorenz Kuhlee anbefaler generelt - og altså ikke kun i forhold til webservere - at køre en eller anden form for automatiseret proces, der kan checke, om der er blevet pillet ved filer.

Når det ifølge ham er et must at checke fil-integriteten på netop en webserver, så hænger det - måske ikke helt overraskende - sammen med, at den type servere i sagens natur er tilgængelige fra internettet.

»Så de er et mål, der let kan nås af alle. Alle kan forsøge at manipulere serveren, så det er en god idé at have dette (integritetscheck, red.),« siger han.

I forhold til at checke fil-integriteten, så er det ikke nok bare at scanne efter, om en php-fil har fået fjernet eller tilføjet en ekstra kodelinje på et tidspunkt, hvor det ikke burde være sket. Også sådan noget som ændringer i billedfiler, bør der scannes efter.

»Ja, også billedfiler. Jeg har haft en sag, hvor følsomme data var tilføjet en billedfil. Og så blev billedfilen hentet via nettet. Det var exfiltration-metoden,« siger Kuhlee.

Check ofte

Det er en god idé at checke fil-integriteten ofte, mener Kuhlee. Men sådan et check koster også ressourcer på serveren. Og derfor er det en afvejning, hvor ofte tjekket bør køres, påpeger han.

»Det er svært at svare på. Det kommer virkeligt an på implementeringen. Jo oftere jo bedre. Men du kan ikke checke hvert femte minut, hvis det er tusindvis af filer. Det er svært at sige et tal, det kommer an på situationen på web-serveren. Men mindst to gange om dagen. En løsning kan være at gøre det oftere for kritiske filer, og mindre intensivt for andre filer.«

Uanset hvor ofte fil-integriteten bliver checket, så er giver det ikke en 100 pct. sikkerhed i forhold til at opdage fifleri, påpeger Kuhlee.

Han nævner, at en angriber eksempelvis kan manipulere med filer mellem de to integritetscheck og sørge for, at filerne er tilbage i deres oprindelige tilstand, inden der bliver checket igen.

»Hvis det sker mellem integritets check, så ser du det ikke. Med mindre du også tager højde for time stamps (fil-metadata).«

Der findes flere værktøjer derude til at automatisere checket af fil-integriteten, fortæller Lorenz Kuhlee, som dog ikke ønsker at anbefale et specifikt produkt. Det står naturligvis Version2's læsere frit for at diske op med fif til FIM.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (12)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Ulrik Rasmussen

Det virker altså lidt som en inkompetent lappeløsning det her.

»En eller to linjer, og fra et forensic standpunkt, så er det ofte for omkostningstungt at gennemgå tusindvis af linjer for at finde en eller to linjer.«

Diff?

"Uanset hvor ofte fil-integriteten bliver checket, så er giver det ikke en 100 pct. sikkerhed i forhold til at opdage fifleri, påpeger Kuhlee."

Altså, helt ærligt, hvorfor ikke bare signere alle filer med en private nøgle der ikke ligger på serveren, og få fortolkeren til at verificere den hver gang den læser koden fra disken? En grænse på max 12 timer hvor din server har eksekveret arbitrær kode er altså ikke en særlig overbevisende sikkerhedsgaranti.

Derudover burde ingen af de processer der har med omverdenen at gøre have skriverettigheder til din kildekode alligevel.

  • 7
  • 3
Michael Kjems

Hvis man nu vil forsøge sig med dette på sin Linux-server, er der så nogen her, der har erfaringer med værktøjer til dette?

Det er næppe nogen super ide at strikke noget sammen med et md5-hash i en database. Der er jo oftest nogen der har haft samme ide, og gjort mere ud af det

  • 4
  • 0
Martin Kofoed

sudo apt-get install inotify-tools.

Det er sådan rimeligt low-level. Jeg har installeret iWatch ovenpå, som kan konfigureres op til at sende mails og lignende i tilfælde af filændringer.

http://iwatch.sourceforge.net/index.html

Det virker. Men altså... Hvis din server er 0wned, er der jo intet til hinder for at slå en sådan mekanisme helt fra. Man kan så håbe på, at en intruder overser /etc/iwatch ...

Nåja, og så støjer iWatch temmelig meget, når man apt-get upgrader sit system, og der er masser af nye apache-moduler, eksempelvis ...

  • 2
  • 0
Uffe Seerup

Altså, helt ærligt, hvorfor ikke bare signere alle filer med en private nøgle der ikke ligger på serveren, og få fortolkeren til at verificere den hver gang den læser koden fra disken?

Ja hvorfor ikke? Hmm. Måske fordi fortolkeren ligger på webserveren?

Derudover burde ingen af de processer der har med omverdenen at gøre have skriverettigheder til din kildekode alligevel.

Nej. Men en privilege escalation vuln kan være alt som forhindrer filer i at blive ændret. Så det er en god pointe at kontrollere integriteten.

Husk på, at fx. kernel.org, linuxfoundation.org og flere associerede sites var kompromitteret igennem næsten en måned før nogen opdagede det. Og det blev kun opdaget fordi nogen undrede sig over en logmeddelelse fra et pakke der ikke burde være installeret på maskinen. Et integritetscheck kunne formentlig have opdaget det tidligere.

  • 4
  • 0
Ulrik Rasmussen

Ja hvorfor ikke? Hmm. Måske fordi fortolkeren ligger på webserveren?

Jeg er ikke sikker på hvordan det skulle være en hindring? Du signerer alle dine filer med en privat nøgle inden du lægger dem op på serveren. Fortolkeren konfigureres til kun at eksekvere kode som er signeret med den pågældende nøgle. Da den private nøgle ikke ligger på serveren kan angriberen ikke producere signeret kode.

  • 3
  • 2
Ulrik Rasmussen

Ah, det er lige gået op for mig at vi muligvis taler forbi hinanden fordi jeg har misforstået hensigten med kontrollen. Jeg forstod på artiklen at man var interesseret i at detektere hvornår nogen har udnyttet en svaghed til at ændre en PHP-fil, og derigennem fået adgang til systemet. Altså at angriberen ikke på anden vis først havde fået adgang og derigennem kunne slå forskellige sikkerhedstjek i fortolkeren fra.

Mit forslag vil naturligvis ikke give nogen mening hvis angriberen allerede har fået fuld adgang.

  • 2
  • 0
Thomas Nielsen

En anden detalje ved den oprindelige forståelse, er jo også at svagheden kan eksistere i helt valid kode - altså programmeringsfejl eller protokolsvagheder. Kode som man uden anelse om fejl signerer og forlader sig på korrektheden af. For den største fejl man kan begå, er uden tvivl at stole hovedløst på sin egen ufejlbarlighed.

  • 1
  • 0
Tobias Tobiasen

Er der en god måde at teste docker images på? Det må med fordel gøres på hosten det vil nedsætte risikoen for at angriberen kan ændre programmet der checker om noget er ændret.

  • 0
  • 0
Kjeld Flarup Christensen

Man kunne jo også placere filerne på et read only file system, f.eks. via NFS eller en mount bind på LXC. Så skal integriteten nok holde.

I øvrigt et det mest tåbelige ved de fleste CMS systemer dette her: https://website.com/admin Hvorfor pokker skal administrations interfacet køre på samme webserver som produktionen. I stedet skal man lave https://admin.website.com, som kan køre på en anden webserver, hvor der er RW adgang til filerne, og samtidigt med en firewall, eller endnu bedre den kører kun på intranettet.

Og det samme med databasen, admin serveren skal kunne alt, mens produktionsserveren, kun får rettigheder på et need to know basis.

Det er lykkedes mig at sætte en wordpress op med to servere. Databasen derimod gav jeg op overfor.

  • 0
  • 0
Log ind eller Opret konto for at kommentere