VPN APT-forrás: mit engedélyez, és hogyan korlátozzuk

Egy VPN-kliens letöltése egyszeri döntés; az APT-tároló hozzáadása nem az. A második megmondja a csomagkezelőnek, honnan jöhet jövőbeli szoftver, és ez állandó hatáskör-átruházás, nem letöltés. Ez lehet a helyes megoldás, ha a szállító megfelelően karbantart egy tárolót. Mégis megfontolt döntést érdemel, és a legtöbb telepítési útmutató kihagyja.

Az aláírás egy archívumot hitelesít, nem a kódját

Az APT ellenőrzi a tároló aláírt metaadatait, majd megbízik az azokban lévő ellenőrzőösszegekben a letöltött csomagok esetében. Ez azt bizonyítja, hogy az archívum megegyezik azzal, amit a kulcs tulajdonosa közzétett, és semmit sem mond a benne lévő kódról. Egy helyesen aláírt csomag továbbra is tartalmazhat nem biztonságos karbantartói szkripteket, és ezek a szkriptek rootként futnak a csomag telepítése közben. Az apt-secure kézikönyv pontosan ezt a határvonalat húzza meg az archívum hitelesítése és a szoftver átvizsgálása között.

A hasznos kérdés tehát nem az, hogy érvényes-e az aláírás, hiszen a törött aláírás úgyis leállítja a telepítést. Hanem az, hogy kinek az aláírásában dönt mostantól megbízni. Egy ellopott aláírókulcs rosszabb, mint egy ellopott csomag, mert a támadó még sokáig gyárt érvényes metaadatokat az első rossz kiadás után. Csak a kulcscsere jelent javítást, és azon múlik, hogy a szállító új kulcsot tesz közzé egy olyan csatornán, amelyet önállóan ellenőrizhet.

Ezért a kulcs személyazonossága legalább annyi figyelmet érdemel, mint a tároló URL-je. Egy régi fórumválaszban szereplő címről vett kulcs semmit sem bizonyít a kiadóról, míg a HTTPS csak a szállítást védi addig, aki felvette a telefont. A szállítás biztonsága és a kiadó személyazonossága külön kérdés, és csak az elsőt oldja meg egy tanúsítvány.

A kulcsot a forrásra szűkítse, ne a rendszerre

A modern APT elfogad egy forrásspecifikus Signed-By hivatkozást. Az üzemeltető által kezelt kulcs élhet a /etc/apt/keyrings/ alatt, és a forrásbejegyzés megnevezi a kulcsot, amely jogosult az archívum hitelesítésére. Ez szűkebb, mint ugyanazt a kulcsot egy globálisan megbízható halmazba dobni, ahol olyan forrásokért is kezeskedhet, amelyeket soha nem akart engedélyezni. Kövesse a telepített APT-verziót és a szállító aktuális utasításait, ahelyett hogy különböző generációs útmutatók töredékeit keverné.

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

Soha ne javítson aláírási hibát az ellenőrzés kikapcsolásával vagy egy ismeretlen archívum megbízhatóként jelölésével. Ez látható hibát cserél láthatatlanra, és a láthatatlan addig tart, amíg valaki nem auditálja a forráslistát. Ha a kulcs nem egyezik, a helyes javítás a megfelelő kulcs megtalálása, nem az ellenőrzés eltávolítása.

Szerezze be a tároló adatait és a kulcs személyazonosságát a projekttől vagy egy kezelt adminisztrátortól. Egy blogbejegyzésből másolt kulcs állítás a szerzőségről, nem bizonyíték rá. Amikor a szállító kulcscsere-csatornát tesz közzé, jegyezze fel a kulccsal együtt, mert ez a csatorna teszi lehetővé a következő cserét.

A forrás rögzítése nem csomag-engedélylista

Egy kulcs egy forrásra szűkítése azt korlátozza, melyik archívumot hitelesítheti, nem azt, hogy az az archívum mely csomagokat tehet közzé. A tároló jóval többet szállíthat a kívánt VPN-kliensnél, és az APT jelöltválasztása és prioritásai döntik el, melyik jogosult verzió nyer. Tekintse át a javasolt tranzakciót a megerősítés előtt, a függőségi listát is beleértve, mert a függőségek ugyanabból az archívumból jönnek. Egy kulcs hatóköre nem tudja kifejezni, hogy ’csak ez a csomag’.

Ha erősebb ellenőrzésre van szüksége, fejezze ki csomagnevekre vagy verziókra vonatkozó szabályzatként, és tartsa ezt a szabályzatot konfigurációkezelés alatt. Egy tranzakció elolvasása egy percet vesz igénybe; egy váratlan csomag felfedezése hat hónappal később egy felülvizsgálatot.

A váratlan csomagok a megállás pillanatai, nem a továbblépésé, és a kérdés az archívum tulajdonosához az, miért szükségesek. Egy tároló, amely egy kliens körül egy tucat csomagot tesz közzé, normális egy asztali csomagot szállító szállítónál. Ez nagyobb felület is, mint amit a telepítési útmutató sugallt, és éppen ezt a részt érdemes feljegyezni. Egyik kimenet sem ok arra, hogy megkérdőjelezze az aláírást; mindkettő ok arra, hogy leírja, mit fogadott el.

Jegyezze fel a hatáskört és annak eltávolítását

Írja le az archívum tulajdonosát, a támogatott operációsrendszer-kiadást, a kulcscsere-csatornát és az eltávolítási eljárást. Ez a négy tény az, amire egy utódnak szüksége van, amikor a kliens kivonul, vagy a szállító cseréli a kulcsát. Ezek nélkül a következő ember egy forrássort és egy kulcsfájlt örököl minden történet nélkül.

Az eltávolítás az a lépés, amelyet kihagynak, ezért már telepítéskor írja le. Törölje a forrásbejegyzést és a hozzá tartozó kulcsot együtt, és a fájl törlése előtt ellenőrizze, hivatkozik-e máshol erre a kulcsra. Egy megosztott kulcs, amelyet ezen ellenőrzés nélkül törölnek, a tisztítást egy független kieséssé változtatja, ami rutinváltozás esetén a legrosszabb eredmény. Ezután erősítse meg, hogy a szokásos frissítések a bejegyzés eltűnése után is feloldódnak.

Egy dolog marad a tároló eltávolítása után: minden onnan már telepített csomag tovább fut, amíg valami le nem cseréli. Az őszinte kérdés az, milyen hatáskört adott hozzá, és milyen szűken fejeződött ki a szerepe.