Gaat die OpenVPN-beveiligingsfix überhaupt over jouw installatie?

Het advies om de client te patchen zodat hij certificaten valideert, is te vaag om op te handelen. Het kan een opgelost softwaredefect beschrijven, een oude build van één aanbieder, of een profiel dat de controle nooit heeft gevraagd. Dat zijn drie verschillende wijzigingen met drie verschillende eigenaren. Op die zin handelen zonder te weten welke van de drie je tegenover je hebt, is hoe een werkende client zonder reden wordt aangepast.

Scheid de drie beweringen

Een softwaredefect heeft een advies, getroffen versies en een opgeloste release. Een aanbiederbuild heeft zijn eigen distributiekanaal en zijn eigen updatetempo. Een profielweglating heeft geen van beide, omdat het uitvoerbare bestand in orde is en de configuratie minder vraagt dan je aannam. Tot de bewering een van die drie noemt, valt er niets te testen.

Schrijf de bewering in één zin voordat je ernaar zoekt. Als de zin niet kan benoemen wat er stuk is, heeft de zoektocht geen doel en lijkt elk resultaat relevant.

Vind het uitvoerbare bestand dat echt draait

Bepaal wat de verbinding start voordat je naar welke versie dan ook kijkt. Een distributieservice, een desktopplug-in en een leveranciersapplicatie kunnen elk een ander uitvoerbaar bestand of een andere engine gebruiken. Een versie die door welke binary dan ook wordt afgedrukt die toevallig in het zoekpad van de shell staat, is geen inventaris van de machine. Lees de unit of het proces dat de verbinding werkelijk tot stand bracht.

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

De pakketquery meldt wat lokale metadata denken dat geïnstalleerd en beschikbaar is, en die cache kan verouderd zijn, dus ververs hem eerst. Hij zegt ook niets over of de draaiende service een binary heeft geladen die vijf minuten geleden is geïnstalleerd. Vergelijk het pakketrecord met het proces dat werkelijk verbonden is.

Pakketbewijs in plaats van versie-indrukken

Beveiligingsonderhoud van distributies backport vaak fixes, dus een ouder uitziende upstream-versie kan de patch nog bevatten. Het omgekeerde geldt ook: een pakket uit een onbekende repository heeft geen automatische aanspraak op actueel onderhoud. Lees de supportstatus van de release, niet het versienummer.

Dat onderscheid is het verschil tussen een echt gat en een nummer dat er alleen oud uitziet. Noteer de repository waar het pakket vandaan kwam, want dezelfde versiestring kan via heel verschillende kanalen met heel verschillende ondersteuning aankomen.

Configuratie is de andere helft

Een onderhouden uitvoerbaar bestand heeft nog steeds een profiel nodig dat de controles vraagt waarvan je denkt dat ze aanwezig zijn. Vertrouwensankers, de bedoelde rol van de tegenpartij en de verwachte servernaam zijn verwante maar aparte beslissingen. Een rolcontrole is geen naamcontrole, en geen van beide vervangt de andere. Als de waarschuwing over configuratie gaat, is de oplossing aan wie het profiel bezit.

Installeer geen willekeurige patch om een ongeverifieerd profiel te compenseren, en voeg geen richtlijn toe om een echt implementatiedefect te repareren. Beide fouten voelen als vooruitgang, daarom blijven beide gebeuren.

Beslis met bewijs in het record

De beslissing volgt uit wat je hebt vastgesteld. Een gedocumenteerd getroffen pakket vraagt om zijn ondersteunde update, een niet-ondersteund platform heeft een migratiepad nodig, en een leveranciersclient heeft de begeleiding van die leverancier nodig. Een dubbelzinnige instructie heeft een advies en een getroffen component nodig voordat een van die dingen van toepassing is.

Houd de actieve client, de volledige versie, het advies en de profieleigenaar samen in het wijzigingsrecord. Dat is sterker dan een tutorialverwijzing, en dat is wat de volgende persoon echt nodig heeft.