VPN APT-kilde: hva den gir, og hvordan du begrenser den

Å laste ned en VPN-klient er en engangsbeslutning; å legge til APT-lageret dens er det ikke. Det andre forteller pakkebehandleren hvor fremtidig programvare kan komme fra, og det er en varig overføring av myndighet snarere enn en nedlasting. Det kan være den riktige ordningen når leverandøren vedlikeholder et lager skikkelig. Det fortjener likevel en bevisst beslutning, og de fleste installasjonsveiledninger hopper over det.

En signatur bekrefter et arkiv, ikke koden i det

APT verifiserer signerte lagermetadata og stoler deretter på kontrollsummene i disse metadataene for pakkene den henter. Det beviser at arkivet samsvarer med det nøkkelinnehaveren publiserte, og ingenting om koden inni. En korrekt signert pakke kan fortsatt inneholde utrygge vedlikeholderskript, og disse skriptene kjører som root mens pakken installeres. apt-secure-håndboken trekker nettopp denne grensen mellom arkivbekreftelse og en gjennomgang av programvaren.

Så det nyttige spørsmålet er ikke om signaturen validerer, siden en brutt signatur stopper installasjonen uansett. Det er hvis signatur du fra nå av velger å stole på. En stjålet signeringsnøkkel er verre enn en stjålet pakke, fordi angriperen fortsetter å produsere gyldige metadata lenge etter den første dårlige utgivelsen. Rotasjon er den eneste reparasjonen, og den avhenger av at leverandøren publiserer en ny nøkkel gjennom en kanal du kan verifisere uavhengig.

Derfor fortjener nøkkelidentiteten like mye oppmerksomhet som lagerets URL. En nøkkel hentet fra en adresse i et gammelt forumssvar fastslår ingenting om utgiveren, mens HTTPS beskytter transporten til den som svarte på telefonen. Transportsikkerhet og utgiveridentitet er separate spørsmål, og bare det første løses av et sertifikat.

Begrens nøkkelen til kilden, ikke til systemet

Moderne APT godtar en kildespesifikk Signed-By-referanse. En operatørstyrt nøkkel kan ligge under /etc/apt/keyrings/, og kildeoppføringen navngir nøkkelen som kan bekrefte det arkivet. Det er smalere enn å kaste den samme nøkkelen i et globalt klarert sett, der den kan gå god for kilder du aldri mente å tillate. Følg den installerte APT-versjonen og leverandørens gjeldende instruksjoner i stedet for å blande fragmenter fra ulike generasjoner av veiledninger.

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

Reparer aldri en signaturfeil ved å slå av verifiseringen eller merke et ukjent arkiv som klarert. Det bytter en synlig feil mot en usynlig, og den usynlige varer til noen reviderer kildelisten. Hvis nøkkelen ikke passer, er den riktige løsningen å finne den riktige nøkkelen, ikke å fjerne kontrollen.

Få lagerdetaljene og nøkkelidentiteten fra prosjektet eller en administrert administrator. En nøkkel kopiert fra et blogginnlegg er en påstand om forfatterskap, ikke bevis for det. Når en leverandør publiserer en rotasjonskanal, noter den sammen med nøkkelen, fordi den kanalen er det som gjør den neste rotasjonen mulig.

Kildepinning er ikke en pakke-tillatelsesliste

Å begrense en nøkkel til én kilde begrenser hvilket arkiv den kan bekrefte, ikke hvilke pakker det arkivet kan publisere. Lageret kan levere mye mer enn VPN-klienten du ønsket, og APTs kandidatvalg og prioriteter avgjør hvilken kvalifisert versjon som vinner. Gå gjennom den foreslåtte transaksjonen før du bekrefter den, inkludert avhengighetslisten, fordi avhengigheter kommer fra samme arkiv. En nøkkelramme kan ikke uttrykke ’bare denne pakken’.

Hvis du trenger sterkere kontroll, uttrykk det som policy for pakkenavn eller -versjoner og hold den policyen under konfigurasjonsstyring. Å lese en transaksjon tar et minutt; å oppdage en uventet pakke seks måneder senere tar en gjennomgang.

Uventede pakker er øyeblikket for å stoppe snarere enn å fortsette, og spørsmålet til arkiveieren er hvorfor de er nødvendige. Et lager som publiserer et dusin pakker rundt én klient, er normalt for en leverandør som leverer en skrivebordssuite. Det er også en større flate enn installasjonsveiledningen antydet, og det er den delen som er verdt å notere. Ingen av de to utfallene er en grunn til å mistro signaturen; begge er grunner til å skrive ned hva du godtok.

Noter myndigheten og hvordan den fjernes

Skriv ned arkiveieren, den støttede operativsystemutgivelsen, nøkkelrotasjonskanalen og fjernelsesprosedyren. De fire fakta er det en etterfølger trenger når klienten fases ut eller leverandøren roterer nøkkelen sin. Uten dem arver den neste personen en kildelinje og en nøkkelfil uten noen historie.

Fjerning er trinnet som hoppes over, så skriv det ned ved installasjonen. Slett kildeoppføringen og dens dedikerte nøkkel sammen, og sjekk om nøkkelen er referert andre steder før du fjerner filen. En delt nøkkel slettet uten den kontrollen gjør en opprydding til en urelatert avbrudd, som er det verste utfallet for en rutineendring. Bekreft deretter at vanlige oppdateringer fortsatt løses når oppføringen er borte.

Én ting gjenstår etter at lageret er fjernet: enhver pakke som allerede er installert derfra, fortsetter å kjøre til noe erstatter den. Det ærlige spørsmålet er hvilken myndighet du la til, og hvor smalt rollen dens ble uttrykt.