Vi har lige måtte lide den tort at annoncere at der var et DoS hul I Varnish 6.x.
Jeg har skrevet mine tanker om det ovre i min "rant" sektion i Varnish projektet, men jeg kunne egentlig godt tænke mig at høre hvad folk har af input til denne del:
An event like this is a good chance to "recalculate the route" so to speak, and the first question we need to answer is if we are barking up the wrong tree?
Does it matter in the real world, that Varnish does not spit out a handful of CVE's per year ?
Would the significant amount of time we spend on trying to prevent that be better used to extend Varnish ?
There is no doubt that part of Varnish Cache's success is that it is largely "fire & forget".
Every so often I get an email from "the new guy" who just found a Varnish instance which has been running for years, unbeknownst to everybody still in the company.
There are still Varnish 2.x and 3.x out there, running serious workloads without making a fuzz about it.
But is that actually a good thing ?
Dan Geer thinks not, he has argued that all software should have a firm expiry date, to prevent cyberspace ending as a "Cybersecurity SuperFund Site".
So far our two big security issues have both been DoS vulnerabilities, and Varnish recovers as soon as the attack ends, but what if the next one is a data-disclosure issue ?
When Varnish users are not used to patch their Varnish instance, would they even notice the security advisory, or would they obliviously keep running the vulnerable code for years on end ?
Of course, updating a software package has never been easier, in a well-run installation it should be a non-event which happens automatically.
And in a world where August 2019 saw a grand total of 2004 CVEs, how much should we (still) cater to people who "fire & forget" ?
And finally we must ask ourselves if all the effort we spend on code quality is worth it, if we still face a major security issue as often as every other year ?
Hvor er vi egentlig henne med sikkerhed og programkvalitet nu om dage ?
phk
Hvilket groft sagt er den problemstilling f.eks. Lets Encrypt har løst ved at sige:
Well, du kan lige så godt, med det samme, få styr på din opdaterings-strategi, for du for brug for den om 3 måneder...
Som så igen ikke nødvendigvist er en hindring for at new guy staidg dukker op og finder en glemt produktions-server i fuld sving med opgaver - hvis tingene bare er gjort rigtigt
med det samme, få styr på din opdaterings-strategi
Enig.
Men når ting sker automatisk, hvad sker der så når det går galt? Der er ikke nogle i virksomhen, som har en jordisk chance for at vide hvad der er galt eller hvor de skal starte med at debugge, når "systemet" har gjort det automatisk i årevis.
Og det er endnu værre ved mange npm pakker. Her kan en opgradering fra version 15.6.2.1 til 15.6.2.2 betyde at ens system går fuldstændig ned, fordi kvaliteten af versioning er dårlig. Det burde ikke betyde breaking changes, men hvad der er en bug for nogle kan være en feature for andre.
Det kan være røvsygt arbejde at sikre at man er compliant med OWASP A9:2017 (Using Components with Known Vulnerabilities) og automatisering (som ved Let's Encrypt) er fint - men hvad så når det lige pludselig ikke viker?
Min pointe er måske at ens opdaterings-strategi ikke bør stoppe ved at sige "nu har jeg automatiseret det, så har vi styr på det". Der bliver nødt til at være nogle med god gammeldags know-how om systemets interne komponenter og dens krydsafhængigheder til tredjepart software.
So far our two big security issues have both been DoS vulnerabilities, and Varnish recovers as soon as the attack ends, but what if the next one is a data-disclosure issue ?
Kan det skade andre ? En ting er at det skader brugeren af softwaren. Problemet er, når det (kan) skade(r) andre.
Hvis en fejl kan skade andre bør der i princippet være en stop knap, som stopper systemet indtil fejlen er rettet.
Software som Varnish skal vel have lov til at fortsætte i den version de er i, indtil der ikke længere leveres patches. Når denne service er overstået skal man så opgradere.
Problemet med rigtigt god software er at folk har en tendens til at glemme om det. Hvis der er service aftale kan den falde imellem stole når der er udskiftning i virksomheden.
Det sker specielt hvis der er tale om billig eller open source software. Hvis denne software fungere så godt at folk glemmer om det og det ikke har en post i regnskabet, så får det klart nok ikke så meget fokus.
Jeg har flere gange oplevet at software har fået mere opmærksomhed fra ledelse og IT-afdeling, hvis der er tale om elendig software.
Og det burde vel for h... være normen og ikke undtagelsen, burde det ikke ?
PHK - nu er det jo ikke din opgave at redde verden, men er der et sted, hvor man kan finde dine vigtigste guldkorn i forhold til softwarekvalitet?
Jeg husker at have set din Varnish roadshow-præsentation for år tilbage, der bl.a. indeholder nogle highlights i forhold til performance-optimering, og så er man som læser af din blog vist heller ikke i tvlv om, at du holder af assert() - men er der et sted, hvor du har samlet de vigtigste elementer, som burde indgå i softwarehåndværkerens værktøjskasse?
Kun folk med for meget tid synes at det er sjovt at passe og pleje installeret software. Vi andre ønsker kun at installere det een gang og så ikke tænke mere over det.
Automatisk opdateringer lyder besnærende, men vil kun virke hvis softwaren altid er bagudkompatibel og aldrig fjerner features. Noget software er flinkt til det, men det meste er ikke. Man kan ikke på forhånd vide om et stykke software vil være bagudkompatiel i fremtiden, så øhm...
Så jeg vil mene at den eneste farbare vej for fire-and-forget er at sikre høj kvalitet.
Jeg husker at have set din Varnish roadshow-præsentation for år tilbage
Godt spørgsmål, Yoel.
Det har jeg desværre ikke set, men jeg har set Jack Ganssles foredrag om softwareudvikling for adskillige år tilbage via omtale på Ingeniøren (og foredraget var så godt, at jeg betragter det som grænsende til obligatorisk undervisning for embedded software-udviklere), så lad mig omformulere Yoels spørgsmål...
Poul-Henning: Hvor og hvornår stiller du næste gang op med et foredrag om dine erfaringer med de vigtigste elementer, som burde indgå i softwarehåndværkerens værktøjskasse?
mvh
Morten Brørup
CTO, SmartShare Systems
Poul-Henning: Hvor og hvornår stiller du næste gang op med et foredrag om dine erfaringer med de vigtigste elementer, som burde indgå i softwarehåndværkerens værktøjskasse?
Når der er en god lejlighed og et passende nørdet publikum til det ?
(Det er seriøst ment: Hvor holder man den slags foredrag nu om dage ?)
Når der er en god lejlighed og et passende nørdet publikum til det ?
(Det er seriøst ment: Hvor holder man den slags foredrag nu om dage ?)
Et forslag: BornHack.
Men budskabet må meget gerne nå ud til en videre kreds, så hvis man skal bruge foredrags-modellen bør foredraget optages på video og lægges ud et passende sted sammen med diverse bilag (præsentation, kodestumper etc.).
Selv om foredrag har den fordel, at man kan stille spørgsmål til foredragsholderen, synes jeg personligt selv bedre om mere varige medier som fx blogindlæg, wiki-sider med best practices etc. - hvis det kan indekseres af Google er der også en større chance for at flere får glæde af det.
Time to market, cost etc. er også ofte vigtigt. Det nytter ikke at have ambitioner om at lave den perfekte løsning hvis der ikke er penge til det. Derfor handler det om at vælge det rigtige niveau til den rigtige opgave.
Men man kunne ønske sig at vi satte tempoet lidt ned sådan at der blev råd til bedere kvalitet. Nogen steder. Såfremt Android og iOS var ordentligt designet rent sikkerhedsmæssigt, så ville der ikke ske det store ved at jeg downloader en lav-kvalitets app. Andre steder må kravet være højere kvalitet.
Når vi så kommer til IoT, så brænder det rigtigt på. De fleste kunne ikke drømme om at opdatere firmware på deres IoT devices. Leverandøren stopper typisk ret hurtigt med opdateringer i øvrigt. Og hvis en IoT har en sikkerhedsbrist eller er inficeret så har jeg som bruger lille mulighed for at identificere dette.
Derfor bør devices der er koblet på internettet have en udløbsdato. Denne skal skrives "på pakken" med store venlige bogstaver. Sådan at man ved hvad man køber - inden man køber. Det samme burde nok gælde andre typer software, men der er det ikke så vigtigt.
Selvom jeg prædiker update-update-update dagligt, så skal jeg erkende at have en varnish 4.0.5 kørende på et større site, varnish er faktisk det ældste stykke software i den primære software stak, af den simple grund at det bare virker uden pis, så selv for mig har der ikke været encitament til at få den opgraderet.
Men sådan er det næsten aldrig, jeg mener at alle skal vænne sig til rullende opdateringer, og det gør vi bedst ved tvang, vha. software releases med relativ kort levetid - det betyder at alle vænner sig til at gøre ting på en måde så det netop ikke bliver for besværligt at opgradere.
Hvis alt (eller det meste) software bare virkede, så ville man stoppe med at lave løbende opdateringer, så på en måde er det nok meget godt at der er 95% møg software og ikke 95% kvalitets software.
Men det giver da en stor personlig glæde, at der faktisk er software som ikke er en uendelig kamp at betjene og holde opdateret.
Tak PHK, og VS Teamet.
Men budskabet må meget gerne nå ud til en videre kreds, så hvis man skal bruge foredrags-modellen bør foredraget optages på video og lægges ud et passende sted sammen med diverse bilag (præsentation, kodestumper etc.).
Foredrag på BornHack har været optaget siden første år, hvor jeg selv sad ved kameraet til samtlige foredrag der blev optaget... :-)
https://www.youtube.com/channel/UCsfj7Re_0IG9knJsfzNEnjw
Der er heldigvis kommet en del flere operatører til, og i år lykkedes det mig kun at sidde med på sidelinien på et enkelt foredrag. :-)
Det vil være fint med en udløbsdato, et stykke fremme i tiden. Men patch hele tiden uden andet formål end at patche er også tåbeligt.
Så 2 år vil nok være fint hvis der er nyere releases hver 6 måned - Så har man 12-18 mdr levetid. Men jeg bruger ikke produktet. Men at tvinge folk til at opgradere lyder som en god ting.
Nu skal man tænke på at der jo er MEGEN software - man skal holde øje med sikkerheden i og opdatere.. ikke kun Varnish :)
Og varnish er jo også linket til diverse afhængigheder som også kan udstille sårbarheder, hvis ikke de opdateres (medmindre man kompilerer statisk).
Og for dem hvor LTS er for gamle versioner - er det fedt hvis i har et officielt repo man bare kan spejle.. men det er sjældent at de repos har et stable koncept.. Der får man features+security/bug fixes i ét - og så er der et større løbende arbejde i at følge med opdateringerne og justere configs.
Så hvis der generelt blev fokus på at holde sine ting opdateret (her tænker jeg at GDPRs kan hjælpe lidt - da dens formulering umiddelbart betyder at man også skal holde sine servere opdateret).
Fordi jeg stræber efter at benytte den software min distribution leverer (og så opdatere distribution så ofte som jeg har behov for), så er det LANGT nemmere at holde sig opdateret - da man får foræret backports af sikkerhedsfikses (fra både CentOS/RedHat og Ubuntu/Debian). Også til deres halv-årlige releases (bare i korter tid).
Når det så gælder de enkelte interne software projekter (python, npm etc.) og deres lib afhængigheder - er der diverse ting der - men det er lidt udenfor her tænker jeg :)
Det der er udenfor skal man have andre procedurer for.. Jeg har den strategi at jeg altid pakker alt - så jeg kan køre det på samme måde som resten - og så diverse scripts til at holde øje med CVE'er for software udenfor distro'ens udvalg.
Personligt er det jeg helst får op at køre -
Til Docker/Kubernetes miljøer:
Hav styr på det image man bygger ALT på (og sikrer sig at det er opdateret) - og ligeledes benytter ovenstående pakker af ekstern software når jeg bygger docker images.
På den måde skal jeg bare sikre mig at rebuild'e docker images for "relevante projekter" (det kan automatiseres så det sker automatisk) og udrulle (kan igen sættes til at ske automatisk - med automatisk graduel rollout og rollback hvis nødvendigt) - og da det gøres via CI - har man en masse "virker min kode stadigvæk"-tests - som hvis "miljøet omkring fejler" - dvs. de ting docker billedet fik fra pakke-repos, så fejler de tests også og udrulningen stopper der til nogen kigger på det.
Til VMs/fysiske servere:
en fuldautomatisk opgraderingsstrategi - hvor alle servere automatisk bliver opdateret på aftalte tidspunkter.
Serverne er delt op i 4 grupperinger.. Dev, test og prod1 og prod 2 (hvor prod 2 er dem vi IKKE har 2 af og derfor bare kan fejle over til den anden af).
Og så bruger jeg et snapshot script som faktisk følger med linux kernen til at lave snapshots af repos (vha. hardlinks) - og så snapshottes repos f.ex. hver 4. uge (normalt når en opdatering ikke skal pushes igennem hurtigere) - og så skifter man bare en server-gruppe til det nye snapshot - 1 af gangen - og det udrulles så automatisk på serverne på et bestemt tidspunkt, hvor man ved man skal holde ekstra øje (og der er folk på arbejde til at fikse evt. problemer).
Derfor bør devices der er koblet på internettet have en udløbsdato.
Den eneste enhed som er direkte på internettet er typisk din xDSL-router/cabelmodem/...,, så jeg tror ikke at det er det som du henviser til.
Så det må være enheder som også indirekte potentielt kan snakke med internettet. Det er en ganske anden og betydelig større mængde, og inkluderer printere ("cloudprint" lal) og vaskemaskiner (styr din vaskemaskine med mobiltelefonen).
Producenten giver typisk 2 års garanti/reklamationsret, men jeg håber da at min nyindkøbte printer holder længere end det. Hr og Fru Jensen checker ikke om producenten garanterer firmwareopdateringer i 10 år på deres vaskemaskine. Hvad gør vi når det opdages at en 5 år gammel vaskemaskine er sårbar overfor MITM-angreb når den snakker med sin "cloudwash" service? Hvad hvis producenten er gået konkurs?
Ja, vi har et gigantisk problem med de nye internetenablede enheder, og jeg kan ikke se hvordan markedet selv kan løse det selv, for producenterne ser det ikke som konkurrenceparameter. Der skal lovgivning til.
Jeg ved udemærket godt hvad din holdning er til at andre folk skal udtale sig om hvad din holdning er. I dette indlæg vil jeg nok forbryde mig mod den regel.
Havde din motivation været af en ren kommerciel interesse kunne jeg have forholdt mig til grundessens af den første del af dit spørgsmål. Jeg acceptere således ikke præmissen om at du kunne have fået produktet til hvor det er hvis ikke du havde haft dine no nonsens principper med fra starten. Jeg husker tydeligt hvordan der blev skrevet om tilgangen til asserts osv. Fra starten.
Jeg vil ikke afvise at spørgsmålet havde været relevant hvis man sad i et mødelokale og talte om at optimere antallet af vedligeholdelseskontrakter eller service timer til opgraderinger.
Grundlæggende er min opfattelse at mængden af programkvaliteten/sikkerheden har været nogenlunde konstant i hele det her år-tusind. Men mængden af software er stigende - derfor er problemet stigende.
På min arbejdsplads er emnet nu noget der håndteres er mere end 1 fuldtidsstilling(har ca. 700 endpoints)
Jeg vil ikke afvise at spørgsmålet havde været relevant hvis man sad i et mødelokale og talte om at optimere antallet af vedligeholdelseskontrakter eller service timer til opgraderinger.
Men det er faktisk lidt det vi gør i projektet for tiden.
HTTP/3 aka QUIC er en meget bedre protocol end HTTP/2 og vi har ikke uendelige resourcer.
H3 er ikke ligefrem "en-mands-protokol" og nok slet ikke hvis den ene mand er totalt CDO med softwarekvaliteten.
Jeg husker at have set din Varnish roadshow-præsentation for år tilbage, der bl.a. indeholder nogle highlights i forhold til performance-optimering
Sikkert denne her: https://www.youtube.com/watch?v=37JNC-TKAis
Den eneste enhed som er direkte på internettet er typisk din xDSL-router/cabelmodem/...,, så jeg tror ikke at det er det som du henviser til.
Så det må være enheder som også indirekte potentielt kan snakke med internettet.
Ja det er netop de de indirekte enheder jeg hentyder til. De er ikke nødvendigvis det første sted malware kan komme ind, men de er et sted hvor det kan gemme sig. En malware der har gemt sig i en internet-enabled el-pære vil være næsten umulig at opdage ... med mindre den laver en masse ravage.
Derfor er der faktisk større behov for høj softwarekvalitet i IoT dimser end i software til en desktop computer. For almindelige brugere vil sørge for at holde deres desktop computer opdateret.
I øvrigt mener jeg at software kvalitet der bygges ind fra starten ikke koster alverden. Når man designer software til at kunne testes, så ender det sjovt nok også med at være mere modulært. Det at jagte tæt ved 100% coverage på unit tests koster penge, men at jagte fejl længe efter de er lavet er også dyrt. Der hvor software kvalitet bliver dyrt er når det skal skabes på bagkanten.
Derfor bør devices der er koblet på internettet have en udløbsdato. Denne skal skrives "på pakken" med store venlige bogstaver.
Nu er der en række enheder, som får IOT status, for at være "smart". Vakemaskiner etc.
Men jeg ser da gerne muligheden for at undlade at koble det op, og så er udløbsdatoen irrelevant.
På samme vis kan man jo i industrisammenhænge isolere sine IOT-enheder, så man, om ikke fjerner, så dog mindsker risikoen betragteligt.
Så risikoen er ikke nødvendigvis afhængig af enhedens type, men af opsætning og anvendelse.
Det at jagte tæt ved 100% coverage på unit tests koster penge, men at jagte fejl længe efter de er lavet er også dyrt.
Ja, det er alment kendt at fejl bliver dyrere at rette jo senere de opdages. En fejl som fanges på designtidspunktet er billigere at rette end en som først fanges i QA. En anden måde at betragte det på var Edsger Dijkstra som i EWD1068 argumenterede for at hvis han brugte 1 time mere på at forbedre en artikel/paper så den var lettere at forstå og kunne læses 1 minut hurtigere, så hvis det blot var 60 læsere så var det værd at gøre.
Den samme betragtning kan man gøre for softwarekvalitet: Hvis det tager 5 timer at forbedre kvaliteten i et stykke software og det har den effekt at 200 brugere ikke skal bruge 5 minutter på at undre sig/lave work-arounds/rapportere fejlen, så er det samfundsmæssigt en gevinst (300 minutter < 1000 minutter).
Jeg mener at når udviklere slipper software fri, hvor de billigt kunne have elimineret flere fejl inden da, så må de være arrogante og mene at deres tid er meget mere vigtig end brugernes tid.
Eller også er de blot ikke så kompetente som de selv tror.
Nu er det let at sidde i sit elfenbenstårn og mene at udviklere blot skal lade være med at lave fejl, eller bruge masser af resourcer på at eliminere dem. I praksis koster det mere og mere jo højere kvalitet man stiler efter. 70% coverage koster måske en uge, 80% coverage koster måske to uger mere, 90% coverage koster måske tre uger mere. På et tidspunkt kan det ikke betale sig mere at teste (med en specifik metode), og man bør bruge sine resourcer andre steder. Og lade softwaren undslippe, velvidende at at der stadig kan være fejl i den, men man har gjorst sit til at det er usandsynligt at brugerne vil løbe ind i dem.
HTTP/3 aka QUIC
[snip]
H3 er ikke ligefrem "en-mands-protokol" og nok slet ikke hvis den ene mand er totalt CDO med softwarekvaliteten.
Der må jeg give dig ret. QUIC ligner meget SCTP, med HTTP/2 ovenpå. Så man kan estimere kompleksiteten ret godt.
Har du overvejet at blot tage googles eksempel-server i Go og enten bruge den via TCP, eller linke direkte ind i Varnish? Det kunne være stop-gap indtil nogen laver en solid QUIC implementation som lever op til dine kvalitetskrav.
Jeg mener at når udviklere slipper software fri, hvor de billigt kunne have elimineret flere fejl inden da, så må de være arrogante og mene at deres tid er meget mere vigtig end brugernes tid.
Udviklere der er arrogante?
Nok nærmere management der kræver den hellige time-to-market gral, eller en kunde der er nærig. "Dokumentation og test giver os ikke business value, så det vil vi ikke betale for".
Nok nærmere management der kræver den hellige time-to-market gral, eller en kunde der er nærig. "Dokumentation og test giver os ikke business value, så det vil vi ikke betale for".
Hvis vi skal se indad som udvilklere så må vi vel kunne forklare forretningen hvorfor dokumentation og test giver forretningsværdi.
Hvis det ikke giver forretningsværdi så er der vel heller ingen valid grund til at gøre det.
