Din VPN-nøgle kan læses af alle: hvad du skal rette

Det første tegn er som regel en advarsel, ikke et nedbrud. En klient nægter at indlæse en nøgle, fordi filen kan læses af gruppen eller alle, eller en sikkerhedsgennemgang finder client.key med tilstand 644 i en profilmappe, der også indeholder eksporterede bundter. Intet er gået i stykker endnu, og netop derfor bliver advarslen afvist. Nøglen virker, tunnelen rejser sig, og filen kan læses af enhver konto på maskinen.

Symptomet er en tilladelsesadvarsel, ikke et udfald

På et Unix-lignende system bør en privat nøgle kun kunne læses af den konto, der kører tjenesten. Tilstand 600 med den rigtige ejer er den sædvanlige ordning. Tilstand 644 betyder, at enhver lokal bruger kan kopiere nøglen, og på en delt build-vært er det et reelt publikum.

Klienter, der kontrollerer dette, gør dig en tjeneste. Dem, der ikke gør, er ikke bevis for, at filen er sikker, og en vellykket forbindelse siger intet om, hvem andre der kan læse det materiale, som gjorde den mulig. Behandl advarslen som hele fundet. Den er præcis, og den kom, før nogen kopierede filen.

Tilpas tilstanden til tjenestens identitet

Adgang kun for ejeren passer til en nøgle, som den ejer bruger. En tjeneste med en bevidst delt gruppe kan have brug for en anden kontrolleret ordning, fx gruppelæsning på en nøgle, der ejes af en tjenestekonto. Blindt at sætte alle filer til én numerisk tilstand ødelægger understøttede klienter, og chmod -R 777 er ikke en løsning på noget.

Kontroller ejeren og tjenestekontoen, før du ændrer noget. Offentlige CA-certifikater og private identitetsnøgler har forskellige krav til hemmeligholdelse, selv når de ligger i samme mappe, så en rekursiv tilstand på hele mappen behandler de to som samme objekt.

ls -l /etc/openvpn/client/
stat -c '%U %G %a %n' /etc/openvpn/client/*.key
id openvpn

På andre platforme skal du bruge det dokumenterede nøglelager eller adgangskontrolmodel i stedet for at oversætte Unix-tilstande til et gæt. Et filnavn, der ender på private, er en etiket, ikke en håndhævelsesmekanisme.

Find de kopier, som tilstanden ikke dækker

Editorer, sikkerhedskopier, eksporterede profiler og midlertidige bundter kan hver bevare den samme identitet. Beskyt de kopier efter deres indhold, fordi stramning af den oprindelige fil intet gør for den i sidste måneds tar-arkiv.

En adgangsfrase på en nøglefil er nyttig til lagret materiale og retfærdiggør ikke offentliggørelse af den krypterede fil ved siden af dens adgangskode. Tilladelser beskytter det aktuelle filsystemobjekt; de siger intet om en legitimationsoplysning, der allerede er kopieret andre steder.

Søg efter kopierne, før du erklærer opgaven færdig: grep -rl nøglens overskriftslinje i sandsynlige mapper og et kig på udelukkelser i sikkerhedskopier. Resultatet er som regel mere interessant end den fil, du startede med.

Efter rettelsen: verificér og udskift

Test, at den tilsigtede tjeneste stadig godkender, og bekræft derefter, at ingen unødvendig konto har fået adgang. Hold diagnostisk output begrænset til metadata, fordi udskrivning af nøglen ikke er nødvendig for at bevise, at filen kan læses og det lægger materialet i en log.

Hvis nøglen har været eksponeret, stram tilstanden, og udskift derefter legitimationsoplysningen og tilbagekald den gamle. POSIX chmod-specifikationen forklarer, hvad hver tilstandsbit betyder, hvilket er værd at vide, før den næste gennemgang beder dig begrunde det tal, du valgte.