VPN APT-källa: vad den ger och hur du begränsar den

Att ladda ner en VPN-klient är ett engångsbeslut; att lägga till dess APT-förråd är det inte. Det andra talar om för pakethanteraren varifrån framtida programvara kan komma, och det är en permanent överföring av befogenhet snarare än en nedladdning. Det kan vara rätt ordning när leverantören sköter ett förråd ordentligt. Det förtjänar ändå ett medvetet beslut, och de flesta installationsguider hoppar över det.

En signatur autentiserar ett arkiv, inte dess kod

APT verifierar signerade förrådsmetadata och litar sedan på kontrollsummorna i dessa metadata för de paket den hämtar. Det bevisar att arkivet stämmer med det som nyckelhavaren publicerade, och ingenting om koden inuti. Ett korrekt signerat paket kan fortfarande innehålla osäkra underhållarskript, och dessa skript körs som root medan paketet installeras. apt-secure-handboken drar exakt denna gräns mellan arkivautentisering och en granskning av programvaran.

Så den användbara frågan är inte om signaturen validerar, eftersom en bruten signatur stoppar installationen ändå. Den är vems signatur du från och med nu väljer att lita på. En stulen signeringsnyckel är värre än ett stulet paket, eftersom angriparen fortsätter producera giltiga metadata långt efter den första dåliga utgåvan. Rotation är den enda reparationen, och den beror på att leverantören publicerar en ny nyckel via en kanal som du kan verifiera självständigt.

Därför förtjänar nyckelns identitet lika mycket uppmärksamhet som förrådets URL. En nyckel hämtad från en adress i ett gammalt forumsvar fastställer ingenting om utgivaren, medan HTTPS skyddar transporten till den som svarade i telefonen. Transportsäkerhet och utgivaridentitet är separata frågor, och bara den första löses av ett certifikat.

Begränsa nyckeln till källan, inte till systemet

Modernt APT accepterar en källspecifik Signed-By-referens. En operatörsstyrd nyckel kan ligga under /etc/apt/keyrings/, och källposten namnger den nyckel som får autentisera det arkivet. Det är snävare än att kasta samma nyckel i en globalt betrodd uppsättning, där den kan gå i god för källor du aldrig tänkt tillåta. Följ den installerade APT-versionen och leverantörens aktuella instruktioner i stället för att blanda fragment från olika generationer av guider.

curl -fsSL https://repo.example.com/vpn-key.gpg -o /etc/apt/keyrings/vpn.gpg
echo "deb [signed-by=/etc/apt/keyrings/vpn.gpg] https://repo.example.com/debian stable main" > /etc/apt/sources.list.d/vpn.list

Reparera aldrig ett signaturfel genom att stänga av verifieringen eller markera ett okänt arkiv som betrott. Det byter ett synligt fel mot ett osynligt, och det osynliga varar tills någon granskar källistan. Om nyckeln inte matchar är den korrekta lösningen att hitta rätt nyckel, inte att ta bort kontrollen.

Hämta förrådets uppgifter och nyckelns identitet från projektet eller en hanterad administratör. En nyckel kopierad från ett blogginlägg är ett påstående om upphovsmannaskap, inte bevis för det. När en leverantör publicerar en rotationskanal ska du anteckna den tillsammans med nyckeln, eftersom det är den kanalen som gör nästa rotation möjlig.

Källpinning är inte en paketvitlista

Att begränsa en nyckel till en källa begränsar vilket arkiv den kan autentisera, inte vilka paket det arkivet får publicera. Förrådet kan leverera mycket mer än den VPN-klient du ville ha, och APT:s kandidatval och prioriteringar avgör vilken kvalificerad version som vinner. Granska den föreslagna transaktionen innan du bekräftar den, inklusive beroendelistan, eftersom beroenden kommer från samma arkiv. En nyckelomfattning kan inte uttrycka ’bara det här paketet’.

Om du behöver starkare kontroll, uttryck det som policy för paketnamn eller -versioner och håll den policyn under konfigurationshantering. Att läsa en transaktion tar en minut; att upptäcka ett oväntat paket sex månader senare tar en granskning.

Oväntade paket är ögonblicket att stanna snarare än att fortsätta, och frågan till förrådsägaren är varför de behövs. Ett förråd som publicerar ett dussin paket kring en klient är normalt för en leverantör som levererar en skrivbordssvit. Det är också en större yta än installationsguiden antydde, och det är den delen som är värd att anteckna. Ingen av de två utgångarna är en anledning att misstro signaturen; båda är anledningar att skriva ned vad du accepterade.

Anteckna befogenheten och hur den tas bort

Skriv ned förrådsägaren, den stödda operativsystemutgåvan, nyckelrotationskanalen och borttagningsproceduren. De fyra fakta är vad en efterträdare behöver när klienten fasas ut eller leverantören roterar sin nyckel. Utan dem ärver nästa person en källrad och en nyckelfil utan någon historia.

Borttagning är steget som hoppas över, så skriv ned det vid installationen. Radera källposten och dess dedikerade nyckel tillsammans, och kontrollera om nyckeln refereras någon annanstans innan du tar bort filen. En delad nyckel som raderas utan den kontrollen förvandlar en städning till ett orelaterat avbrott, vilket är det sämsta utfallet för en rutinändring. Bekräfta sedan att vanliga uppdateringar fortfarande löses när posten är borta.

En sak återstår efter att förrådet tagits bort: varje paket som redan installerats därifrån fortsätter att köras tills något ersätter det. Den ärliga frågan är vilken befogenhet du lade till, och hur snävt dess roll uttrycktes.