Handler den OpenVPN-sikkerhetsfiksen egentlig om installasjonen din?

Rådet om å patche klienten slik at den validerer sertifikater er for vagt til å handle på. Det kan beskrive en rettet programvarefeil, et gammelt bygg fra én leverandør, eller en profil som aldri ba om kontrollen. Det er tre forskjellige endringer med tre forskjellige eiere. Å handle på den setningen uten å vite hvilken av dem du står overfor, er hvordan en fungerende klient blir endret uten grunn.

Skill de tre påstandene

En programvarefeil har et varsel, berørte versjoner og en rettet utgivelse. Et leverandørbygg har sin egen distribusjonskanal og sin egen oppdateringstakt. En profilutelatelse har ingen av delene, fordi den kjørende filen er i orden og konfigurasjonen ber om mindre enn du antok. Inntil påstanden navngir én av de tre, er det ingenting å teste.

Skriv påstanden i én setning før du søker etter den. Hvis setningen ikke kan navngi hva som er ødelagt, har søket ingen mål og hvert resultat ser relevant ut.

Finn den kjørende filen som faktisk kjører

Identifiser hva som starter tilkoblingen før du ser på noen versjon. En distribusjonstjeneste, en skrivebordsplugin og en leverandørapplikasjon kan hver bruke en annen kjørende fil eller motor. En versjon som skrives ut av hvilken som helst binærfil som tilfeldigvis ligger i skallens søkesti, er ikke en oversikt over maskinen. Les enheten eller prosessen som faktisk utførte tilkoblingen.

systemctl cat openvpn-client@*.service
ps -o pid,cmd -C openvpn
apt-cache policy openvpn network-manager-openvpn

Pakkespørringen rapporterer hva lokale metadata mener er installert og tilgjengelig, og hurtiglageret kan være utdatert, så oppdater det først. Den sier heller ingenting om hvorvidt tjenesten som kjører lastet inn en binærfil som ble installert for fem minutter siden. Sammenlign pakkeregisteret med prosessen som faktisk er tilkoblet.

Pakkebevis i stedet for versjonsinntrykk

Distribusjonenes sikkerhetsvedlikehold tilbakefører ofte rettelser, så en eldre utseende upstream-versjon kan fortsatt inneholde lappen. Det motsatte gjelder også: en pakke fra et ukjent lager har ingen automatisk rett til gjeldende vedlikehold. Les utgivelsens støttestatus i stedet for versjonsnummeret.

Den forskjellen er forskjellen mellom et reelt hull og et tall som bare ser gammelt ut. Noter lageret pakken kom fra, fordi den samme versjonsstrengen kan ankomme gjennom svært forskjellige kanaler med svært forskjellig støtte.

Konfigurasjonen er den andre halvdelen

En vedlikeholdt kjørende fil trenger fortsatt en profil som ber om kontrollene du tror er på plass. Tillitsankre, motpartens tiltenkte rolle og det forventede servernavnet er beslektede, men atskilte beslutninger. En rollekontroll er ikke en navnekontroll, og ingen av dem erstatter den andre. Hvis advarselen handler om konfigurasjon, tilhører rettelsen den som eier profilen.

Ikke installer en vilkårlig lapp for å kompensere for en uverifisert profil, og ikke legg til et direktiv for å reparere en ekte implementeringsfeil. Begge feilene føles som fremgang, og det er derfor begge fortsetter å skje.

Beslutt med bevis i registeret

Beslutningen følger av det du har fastslått. En dokumentert berørt pakke krever sin støttede oppdatering, en ikke-støttet plattform trenger en migreringsvei, og en leverandørklient trenger den leverandørens veiledning. En tvetydig instruksjon trenger et varsel og en berørt komponent før noe av dette gjelder.

Hold den aktive klienten, den fulle versjonen, varselet og profileieren sammen i endringsregisteret. Det er sterkere enn en opplæringsreferanse, og det er det neste person faktisk vil trenge.