Simon Justesen

Edit: Jeg kan se på Azures statusside, at nedbruddet også betød nedetid hos andre cloud-tjenester end Microsoft, og det derfor må være lokaliseret i CrowdStrikes software. Det ændrer dog ikke på, at jeg stadig mener, man bør overveje at sprede sine aktiviteter til mere end én cloududbyder.

Edit 2: Jeg har erstattet min “rant” med CFCS og Digitaliseringsstyrelsens anbefalinger, de har med garanti mere styr på storskaladrift end jeg har.

—

Der må sidde nogle teknikere og svede nu. Jeg har naturligvis stor sympati med folkene hos CrowdStrike, for jo, gu’ har de skidt i nælderne bigtime, men det er ikke nemt at drifte cloud-software.

Problemet ligger et andet sted: Storskalacentraliseringen af servere og software gået for vidt. Hvis nedbrud har så dybe implikationer verden over, så er der noget, der er helt forkert. Sikkerhedsekspert Peter Kruse fra Clever, nævner i en artikel på TV2, at 70% af top 100 selskaber i verden bruger CrowdStrike, og så er der alle dem, vi ikke hører om.

Jeg er slet ikke i tvivl om, at CrowdStrike normaltvis er dygtige til det, de laver, men det er satme meget tillid at vise et enkelt firma. I 90′erne viste man samme tillid til virksomheder såsom McAfee og Symantec, men da software og opdateringer ikke på samme måde blev automatisk cloud-leveret udenom IT-afdelingen, havde man selv fuld kontrol over afprøve tingene, inden de blev udrullet, så fejl kunne inddæmmes hurtigere.

Det er en anden tid nu, og derfor er der simpelthen nødt til at blive bygget sikkerhedsmekanismer ind i software, så man kan rulle fejlende opdateringer hurtigt tilbage igen. Læser du på Azures-statusside, som jeg linker øverst, kan du se, at supporten foreslår, at man prøver at genstarte sit system 15 gange for at trigge en patch. Det lyder ikke som om, man er i kontrol, hvis du spørger mig.. Det lyder mere, som om man er på nippet til at hidkalde en troldmand, der måske vil fixe problemet med hokus-pokus.

Jeg er stadig forundret over, at 3. parts software i 2024 har så dyb kernel-adgang til operativsystemer, at bugs i drivere/kernel modules kan skabe BSODs og kernel panics aka. bringer dem i knæ, når man i andre dele af et styresystem har arbejdet ufatteligt meget med abstraktionslag, der gør, at man skal tale med hardware gennem et API, og derfor aldrig kommer helt ned til metallet. Man taler også med et API til kernen, men det kan stadig lade sig gøre, at gøre den ustabil.

CrowdStrike flyttede allerede i 2020 en del af Falcon fra kexts (Kernel Extensions) til MacOS’ Endpoint Security Framework, og jeg noterede mig, at hverken MacOS eller Linux blev ramt af gårsdagens nedbrud, så problemerne kan ligge andetsteds på Windows/Azure, men det må tiden vise, når der er mere klarhed over hvem-gjorde-hvad.

Herhjemme er både staten og kommunerne ligeledes bundet op meget ensidigt på f.eks Microsoft-infrastruktur, så jeg gruer da for, hvad et nedbrud kan betyde der. Jeg siger ikke, at andre systemer nødvendigvis er “bedre”, for det har jeg intet belæg for (læsere af denne blog vil vide, at jeg har præferencer ;)), men det er generelt vildt problematisk at placere alle sine æg i en kurv, som et godt ordsprog lyder.

CFCS og Digitaliseringsstyrelsen lavede denne cloud-vejledning tilbage i 2019-2020, hvor man berører emnerne, specifikt afsnit 3.4, 5.1 og 5.7. (Særlig afsnit 3.4 kan få mig til at more mig en smule, når man ved, hvor meget af dansk offentlig IT, der er bundet op på IT-giganter, og proprietært software. Der er et stykke vej fra teori til praksis åbenbart ;))

Links

https://www.crowdstr … s-new-macos-big-sur/
https://www.wired.co … e-global-it-probems/
https://www.dr.dk/ny … lere-steder-i-verden
Artikel - TV2: Gordisk knude..
Artikel - TechCrunch: What we know…

Hvis du driver din egen server eller har ønsker om at gøre det, så må du simpelthen ikke snyde dig selv for sitet selfh.st. Det er en søgemaskine, der har alt hvad hjertet kan begære indenfor selfhosting.

Genialt!

Links

https://selfh.st/apps

Lidt “late to the game”, men bedre sent end aldrig, ik’? ;-)

En af de ting, der undrede mig mest, da jeg var ny Ubuntu-bruger var, at jeg aldrig fik besked med det samme om opgraderingen via app’en “Softwareopdatering”, når der kom en ny Long Term Support-udgave. Det er der en årsag til:

LTS-udgaverne er til dem, der vægter stabilitet over nye features.

Hvis du har sat “Softwareopdatering” til kun at gøre dig opmærksom på nye udgaver ved hver LTS-udgivelse, og du sidder med den gamle Ubuntu 22.04 LTS, så vil du først blive gjort opmærksom på den nye udgave, når det første bugfix-release 24.04.1 LTS kommer d. 15. august 2024. Det giver Canonical tid til at luge ud i de fejl, der evt. har været ved udgivelsen i april 2024.

Bruger du Ubuntu 23.10 (Mantic Minotaur), skulle du gerne have fået besked om opgraderingen allerede nu, evt. kan du skrive

sudo do-release-upgrade

i terminalen, for at igangsætte installationen manuelt (husk som altid backup).

Update: Opgraderingen gik fint. Men jeg skulle faktisk bruge

sudo do-release-upgrade -d

for at tvinge en opgradering frem. ‘-d’ bruges normalt til udviklingsudgivelser, men downloaden identificerer sig som den fulde 24.04 LTS, så den skulle være god nok :) Under opgraderingen vil updateren spørge, om den skal erstatte nogle eksisterende konfigurationsfiler. Har du lavet manuelle ændringer i de pågældende filer, er det en god idé at kigge dem igennem, ellers kan du roligt lade updateren overskrive de eksisterende.

Links

Ubuntu: Noble Numbat Release Notes

Link: English autotranslation (Google translate)

Bag overskriftens kryptiske talrække gemmer der sig den sikkerhedsadvisering, der har været genstand for megen omtale, de sidste mange dage. Det viser sig nemlig, at nogen har sneget en bagdør ind i bestemte udgaver af sourcekoden til xz-utils, der findes på mange Unix-varianter (Linux, BSD’erne m.fl.). Bagdøren findes i version 5.6.0 og 5.6.1 - tarball-udgaven, men ikke i selve Git-repository’et (se opslag på Open Wall, link nederst)

Et lumsk angreb

Det er et rigtig nasty supply-chain-attack, fordi det består af to dele. Dels bruges xz i pakkebygningsfasen til at patche funktionsbiblioteket liblzma med ondsindet kode. Men det går skridtet videre… For når liblzma efter patchingen bliver linket sammen med andre softwarepakker, så vil sårbarheden også eksistere i de pakker, der bygges efterfølgende, og som trækker på funktioner fra liblzma.

Ifølge Hackaday, som jeg linker til nedenunder, gik koden som bagdøren udløser specifikt efter at modificere virkningen af funktionen RSA_public_decrypt.

Funktionen RSA_public_decrypt bruges bl.a. til at validere ssh-nøgler, så som Hackaday også nævner, så kunne det for en person med ondsindede intentioner være en mulighed for at gøre OpenSSH’s auth-proces svagere, og dermed nemmere forbigå de normale sikkerhedsprocedurer, når man logger ind på en server via SSH.

Opdaget ved et tilfælde

For open source-miljøet er det en rigtig ærgerlig situation. Først og fremmest godt at det blev opdaget af en årvågen udvikler. Men også en brat opvågning, fordi der måske har været en naivistisk tilgang til kodedeling, ift. til koderevision, ansvarsfordeling og tillid i Open Source-miljøet helt generelt. Særligt med tanke på, hvordan verden udenfor Open Source-miljøet på bedrøvelig vis tager sig ud i disse tider.

Der er endnu ingen, der med 100% sikkerhed ved, om det ondsindede kode er bestilt arbejde af en stat eller en enkelt persons komplot, men uanset hvad resultatet af undersøgelsen bliver, så bør det give det anledning til ændringer i sikkerhedsprocedurene hos de Linux/Unix-distributioner, der hiver pakker ind udefra.

De pakker udgør fundamentet for f.eks en Linux-distribution, som distribueres til millioner af brugere - erhverv og hobbyister - som dagligt bruger Linux på deres computere - servere-, IoT- eller desktopsystemer. Derfor er Linux-distributionernes udgivere også sidste sidste bastion overfor sikkerhedshuller, og bør give pakkerne det sidste tjek inden udgivelse. Det er måske netop nu, at der skal et skævt magisk AI-sovs ind over arbejdsgangene. Det er ikke sikkert, AI kan løse problemet, men det kan udpege problemområder og lette arbejdsbyrden.

Vi kan sagtens blive enige om, at det på papiret er de enkelte upstream-projekter, der selv skal sørge for, at deres kode er testet for sikkerhedshuller og clean. Men det ville forudsætte, at alle er sikkerhedseksperter, og det kan på ingen måde forventes. Det, der mudrer sagen yderligere til her, er jo, at den person der - tilsyneladende - har injiceret malwaren i projektet har været en betroet bidragsyder på xz-projektet i en del år.

Forskellige tilgange til test

Alle projekter har forskellige test-metoder, nogle mere strukturerede og tilbundsgående end andre. Men bottomline er, at pakkerne, der ender ude hos slutbrugerne skal efterprøves bedre. Hvis det betyder, at mængden af nyudviklede funktioner i en distribution bliver færre og at antallet af udgivelser falder, så må det være sådan, det er.

Måske er det på tide at samle kræfterne et formaliseret samarbejde imellem distributionerne, der tester pakker, som kommer ind upstream? De enkelte distributioner kan ikke overkomme den byrde isoleret set. Der er immervæk tusindvls af pakker i f.eks en Linux-distribution, der skal testes, og det - ideelt set - hver gang, der lander en opdatering til en pakke.

Nogle af de community-baserede Linux-distributioners release- og sikkerhedsteams består af få personer, mens det forholder sig anderledes hos de erhvervsrettede. Men selv de har brug for en håndsrækning fra fællesskabet. Om sikkerhedsbristen, der ligger bag CVE-2024-3094 ville blive opdaget nemmere i et sådan samarbejde, må stå hen i det uvisse - men det må alt andet lige give blod på tanden ift. at få skabt bedre systemer, der kan trawle kode igennem for brister - automatiserede såvel som manuelle.

Tornhøj tillid

Min tillid til Open Source-økosystemet er dog ikke svækket - tværtimod. Man kan aldrig undgå sådanne brister, den her var en af de ubehageligt lumske.

Havde det været et operativsystem baseret på proprietær, lukket kode, så kunne sådan en sikkerhedsbrist givetvis få lov at eksistere et stykke tid. Det er og bliver en illusion, at fordi man ikke offentliggør sin kode, så er man bedre sikret. I bedste fald giver det måske arbejdsro.

Det er sket før, at sikkerhedsbrister ikke er blevet patchet tidsnok i closed-source systemer, som Ars Technicas artikel her nævner.

Debatten omkring dette sikkerhedshul afslører også, hvor hårde folk kan være ved hinanden, og vi skal for alt i verden undgå at folk brænder ud. Netop debatkulturen ift. open source og dette sikkerhedsbrud, vil jeg prøve at behandle i et kommende blogindlæg, for det er et studie for sig.

Links

Tråd fra OpenWall
NISTs CVE-beskrivelse med referencer
Hackadays artikel
Low Level Learning: et kig på sagen fra en sikkerhedseksperts perspektiv

Jeg tror endelig, jeg har fundet et Open Source PHP content management system, der kan matche Umbraco på Microsoft.NET-platformen bare lidt.

Jeg har arbejdet med Umbraco i snart 20 år, og det har altid været en absolut favorit, der har haft stor indflydelse på, hvordan jeg synes CMS’er skal bygges op. Jeg har prøvet ret mange af de åbne systemer - startede med TYPO3 i en årrække, fik enkelte Mambo/Joomla-opgaver, Wordpress, Orchard og Composite C1 (som vist hedder C1 CMS nu).

Det, jeg har manglet på PHP-platformen, har været at kunne skræddersy backenden lige så hurtigt og nemt, som man kan med Umbraco. Det kan godt lyde som en god gang salgsgas fra en hærdet Umbraco-discipel, men det giver sig f.eks udslag i væsentligt kortere oplæringstid, når man skal lære nye website-administratorer op.

Når noget fungerer intuitivt, så løser selv uerfarne brugere hurtigt en arbejdsopgave, og der har mange CMS’er på PHP-platformen efter min mening traditionelt døjet med “feature bloat”. Der har simpelthen været for mange knapper, og måder at gøre tingene på. Det mest optimale er, at designe brugerfladen efter brugernes ønsker, så de føler sig godt tilpas. Ikke, at de skal bruge for meget tid på at lære at navigere i systemet. Less is more.

Enter… Bolt CMS

Bolt CMS bygger på PHP Symphony-platformen, der er et modent framework efterhånden. Jeg kan godt huske, jeg hørte om Symphony tilbage i 00′erne, da jeg begyndte at bruge PHP professionelt, så det er fedt at se, at det stadig findes.

Jeg vil ikke gå så meget i detaljer med grafiske opbygning af administrationen, for den er, som med de fleste CMS’er.

På overfladen, for det smarte ligger i måden, en websiteløsning opbygges på:

Ligesom Umbraco, så definerer du i BoltCMS også din backend med en række felttyper, f.eks et tekstfelt eller et billedfelt på en Content Type, og det danner tilsammen en slags dokumentskabelon for, hvilke felter CMS-brugeren ser i sin backend, når vedkommende f.eks opretter en nyhed.

Bolt CMS kalder kontrollerne ‘Field Types’, og Umbraco kalder dem ‘Data Types’, men det er praktisk talt det samme.

Det smarte er så, at når du har samlet dine felter i f.eks en content type af typen ‘Nyhed’, så oprettes et menupunkt automagisk i venstre side af administrationen, det er så her, CMS-administratoren og brugerne foretager alle redigeringsfunktioner. Du behøver med andre ord ikke lære dine brugere, hvad en Content Type rent teknisk er, du kan bare pege dem over nyhedsektionen og så vil oprettede nyheder have de felter, der definerede din content type: “Overskrift”, “Forfatter” etc.

– “Jamen, det findes også i andre systemer?”, tænker du måske. Korrekt, men oftest som fasttømrede elementer, og så skal man installere ekstra plugins eller måske endda selv have fingrene i kodegryden, hvis man skal udvide funktionaliteten. Det er jo et valg man tager, om man vil det. Her skal du ikke lave alle forbindelserne mellem dine datamodeller og din backend selv. Det klarer CMS’et.

Derfor kan jeg godt lide, at featuren med den fleksible backendopbygning findes som en indbygget del af et CMS, for så ved du, hvad du har, når du skal udforme din løsning - og et godt stykke ud i fremtiden. Det sker yderst sjældent, at en CMS-producent fjerner grundelementerne, for så er det ikke længere samme produkt.

Den samme sikkerhed har du ikke altid med eksterne moduler: Eksterne udvikleres plugins dør indimellem bare ud, når de enten mister interessen eller laver noget nyt. Det sker for alle CMS’er mellem versionsspring, og så er det, at man kan blive tvunget ud i at forsinke en opdatering af et CMS, indtil man har en erstatning klar.

For at opsummere et allerede langt blogindlæg: Jeg synes umiddelbart, at Bolt er et fedt, gennemarbejdet produkt til mindre og mellemstore sites. Når vi over 50 sider i enkelte kategorier, så tror jeg det begynder at knibe med overskueligheden. Men prøv at lege med det, inden du laver dit næste projekt, for at du kan danne dig dit eget indtryk.

Link:
https://boltcms.io/

PS. Du skal være varsom med at rette Bolts alias for en content type, når først det er sat, og folk tilføjer data i CMS’et. Hvis du retter forsvinder det data, der er skrevet i felterne i Bolts administration. Du kan dog altid hoppe i databasen og lave sammenkædningen igen manuelt med en sneaky SQL-sætning, som folkene bag systemet viser her –> https://bolt.tips/en … enaming-contenttypes