VPN-APT-bron: wat dit toestaan, en hoe om dit te beperk

Om ’n VPN-kliënt af te laai is ’n eenmalige besluit; om sy APT-bron by te voeg is nie. Die tweede sê vir die pakketbestuurder waar toekomstige sagteware vandaan mag kom, wat ’n permanente oordrag van gesag is eerder as ’n aflaai. Dit kan die regte reëling wees wanneer die verskaffer ’n bron behoorlik onderhou. Dit verdien steeds ’n doelbewuste besluit, en die meeste installasiegidse slaan dit oor.

’n Handtekening staaf ’n argief, nie sy kode nie

APT verifieer ondertekende bronmetadata en vertrou dan die kontrolesomme binne daardie metadata vir die pakkette wat dit haal. Wat dit bewys, is dat die argief ooreenstem met wat die sleuteleienaar gepubliseer het, niks oor die kode daarin nie. ’n Korrek ondertekende pakket kan steeds onveilige instandhouerskripte bevat, en daardie skripte loop as root terwyl die pakket installeer. Die apt-secure-handleiding trek presies hierdie lyn tussen argiefverifikasie en ’n hersiening van die sagteware.

Die nuttige vraag is dus nie of die handtekening geldig is nie, want ’n stukkende handtekening stop die installasie in elk geval. Dit is wie se handtekening jy van nou af kies om te vertrou. ’n Gesteele ondertekeningsleutel is erger as ’n gesteelde pakket, want die aanvaller bly geldige metadata produseer lank ná die eerste slegte uitgawe. Rotasie is die enigste herstel, en dit hang daarvan af dat die verskaffer ’n nuwe sleutel publiseer deur ’n kanaal wat jy onafhanklik kan verifieer.

Daarom verdien die sleutelidentiteit net soveel aandag as die bron-URL. ’n Sleutel wat uit ’n adres in ’n ou forumantwoord geneem is, bewys niks oor die uitgewer nie, terwyl HTTPS die vervoer na wie ook al die telefoon geantwoord het, beskerm. Vervoersekuriteit en uitgeweridentiteit is aparte vrae, en net die eerste word deur ’n sertifikaat opgelos.

Beperk die sleutel tot die bron, nie die stelsel nie

Moderne APT aanvaar ’n bronspesifieke Signed-By-verwysing. ’n Sleutel wat deur die operateur bestuur word, kan onder /etc/apt/keyrings/ woon, en die broninskrywing noem die sleutel wat daardie argief mag verifieer. Dit is smaller as om dieselfde sleutel in ’n globaal vertroude stel te gooi, waar dit kan instaan vir bronne wat jy nooit wou toelaat nie. Volg die geïnstalleerde APT-weergawe en die verskaffer se huidige instruksies eerder as om fragmente uit verskillende generasies gidse te meng.

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

Moenie ooit ’n handtekeningfout herstel deur verifikasie af te skakel of ’n onbekende argief as vertrou te merk nie. Dit ruil ’n sigbare fout vir ’n onsigbare een, en die onsigbare een hou tot iemand die bronnelys oudit. As die sleutel nie pas nie, is die korrekte oplossing om die regte sleutel te vind, nie om die kontrole te verwyder nie.

Kry die bronbesonderhede en die sleutelidentiteit by die projek of ’n bestuurde administrateur. ’n Sleutel wat uit ’n blogpos gekopieer is, is ’n bewering oor outeurskap, nie bewys daarvan nie. Wanneer ’n verskaffer ’n rotasiekanaal publiseer, teken dit saam met die sleutel aan, want daardie kanaal is wat die volgende rotasie moontlik maak.

Bronvaspenning is nie ’n pakket-keurlys nie

Om ’n sleutel tot een bron te beperk, beperk watter argief dit kan verifieer, nie watter pakkette daardie argief mag publiseer nie. Die bron kan baie meer lewer as die VPN-kliënt wat jy wou hê, en APT se kandidaatkeuse en prioriteite besluit watter geskikte weergawe wen. Hersien die voorgestelde transaksie voordat jy dit bevestig, insluitend die afhanklikheidslys, want afhanklikhede kom uit dieselfde argief. ’n Sleutelbestek kan nie ’net hierdie pakket’ uitdruk nie.

As jy sterker beheer nodig het, druk dit uit as beleid oor pakketname of weergawes en hou daardie beleid onder konfigurasiebestuur. Om ’n transaksie te lees neem ’n minuut; om ses maande later ’n onverwagte pakket te ontdek neem ’n hersiening.

Onverwagte pakkette is die oomblik om te stop eerder as om voort te gaan, en die vraag vir die bron-eienaar is waarom hulle nodig is. ’n Bron wat ’n dosyn pakkette rondom een kliënt publiseer, is normaal vir ’n verskaffer wat ’n werkskermpakket lewer. Dit is ook ’n groter oppervlak as wat die installasiegids geïmpliseer het, en dit is die deel wat werd is om aan te teken. Nie een van die uitkomste is ’n rede om die handtekening te wantrou nie; albei is redes om neer te skryf wat jy aanvaar het.

Teken die gesag aan en hoe om dit te verwyder

Skryf die bron-eienaar neer, die ondersteunde bedryfstelseluitgawe, die sleutelrotasiekanaal en die verwyderingsprosedure. Daardie vier feite is wat ’n opvolger nodig het wanneer die kliënt aftree of die verskaffer sy sleutel roteer. Sonder hulle erf die volgende persoon ’n bronnelyn en ’n sleutellêer sonder enige verhaal.

Verwydering is die stap wat oorgeslaan word, so skryf dit tydens installasie. Vee die broninskrywing en sy toegewyde sleutel saam uit, en kyk of daardie sleutel elders verwys word voordat jy die lêer verwyder. ’n Gedeelde sleutel wat sonder daardie kontrole verwyder word, verander ’n opruiming in ’n onverwante onderbreking, wat die slegste uitkoms vir ’n roetineverandering is. Bevestig dan dat gewone opdaterings steeds oplos nadat die inskrywing weg is.

Een ding bly oor nadat die bron verwyder is: enige pakket wat reeds daaruit geïnstalleer is, bly loop tot iets dit vervang. Die eerlike vraag is watter gesag jy bygevoeg het, en hoe eng sy rol uitgedruk is.