Din VPN-nyckel är läsbar för alla: vad du behöver åtgärda

Det första tecknet är vanligtvis en varning, inte ett haveri. En klient vägrar läsa in en nyckel eftersom filen är läsbar för gruppen eller för alla, eller så hittar en säkerhetsgranskning client.key med behörighet 644 i en profilmapp som också innehåller exporterade paket. Inget har gått sönder ännu, och det är just därför varningen avfärdas. Nyckeln fungerar, tunneln kommer upp, och filen är läsbar för varje konto på maskinen.

Symtomet är en behörighetsvarning, inte ett avbrott

På ett Unix-liknande system bör en privat nyckel bara vara läsbar för kontot som kör tjänsten. Behörighet 600 med rätt ägare är den vanliga ordningen. Behörighet 644 betyder att varje lokal användare kan kopiera nyckeln, och på en delad byggvärd är det en verklig publik.

Klienter som kontrollerar detta gör dig en tjänst. De som inte gör det är inte bevis för att filen är säker, och en lyckad anslutning säger ingenting om vem andra som kan läsa materialet som gjorde den möjlig. Behandla varningen som hela fyndet. Den är korrekt, och den kom innan någon kopierade filen.

Anpassa behörigheten till tjänstens identitet

Åtkomst endast för ägaren passar en nyckel som ägaren använder. En tjänst med en avsiktligt delad grupp kan behöva en annan kontrollerad ordning, till exempel gruppläsning på en nyckel som ägs av ett tjänstekonto. Att blint sätta alla filer till en enda numerisk behörighet bryter stödda klienter, och chmod -R 777 är ingen lösning på något.

Kontrollera ägaren och tjänstekontot innan du ändrar något. Offentliga CA-certifikat och privata identitetsnycklar har olika krav på hemlighållande även när de ligger i samma mapp, så en rekursiv behörighet på hela mappen behandlar båda som samma objekt.

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

På andra plattformar använder du det dokumenterade nyckellagret eller åtkomstkontrollmodellen i stället för att översätta Unix-behörigheter till en gissning. Ett filnamn som slutar på private är en etikett, inte en tvingande mekanism.

Hitta kopiorna som behörigheten inte täcker

Redigerare, säkerhetskopior, exporterade profiler och tillfälliga paket kan var och en behålla samma identitet. Skydda dessa kopior efter deras innehåll, eftersom att strama åt originalfilen inte gör något för den i förra månadens tar-arkiv.

En lösenfras på en nyckelfil är användbar för lagrat material och rättfärdigar inte att publicera den krypterade filen bredvid sitt lösenord. Behörigheter skyddar det aktuella filsystemsobjektet; de säger ingenting om en autentiseringsuppgift som redan kopierats någon annanstans.

Sök efter kopiorna innan du förklarar arbetet klart: grep -rl nyckelns rubrikrad i sannolika mappar, och en titt på undantag för säkerhetskopior. Resultatet är vanligtvis mer intressant än filen du började med.

Efter rättningen, verifiera och byt

Testa att den avsedda tjänsten fortfarande autentiserar, och bekräfta sedan att inget onödigt konto har fått åtkomst. Begränsa diagnostisk utdata till metadata, eftersom det inte behövs för att bevisa att filen är läsbar att skriva ut nyckeln och det lägger materialet i en logg.

Om nyckeln har exponerats, strama åt behörigheten och byt sedan ut autentiseringsuppgiften och återkalla den gamla. POSIX chmod-specifikationen förklarar vad varje behörighetsbit betyder, vilket är värt att veta innan nästa granskning ber dig motivera det valda talet.