APT източник за VPN: какво дава и как да го ограничим

Изтеглянето на VPN клиент е еднократно решение; добавянето на неговото APT хранилище не е. Второто казва на мениджъра на пакети откъде може да идва бъдещ софтуер, а това е постоянно предаване на правомощия, не изтегляне. Това може да е правилната уредба, когато доставчикът поддържа хранилището както трябва. Все пак заслужава съзнателно решение, а повечето ръководства за инсталиране го пропускат.

Подписът удостоверява архив, не неговия код

APT проверява подписаните метаданни на хранилището и след това се доверява на контролните суми в тях за пакетите, които изтегля. Това доказва, че архивът съответства на публикуваното от притежателя на ключа, и нищо за кода в него. Правилно подписан пакет все още може да носи опасни скриптове на поддръжника, а тези скриптове се изпълняват като root, докато пакетът се инсталира. Ръководството apt-secure тегли точно тази граница между удостоверяването на архива и прегледа на софтуера.

Затова полезният въпрос не е дали подписът се валидира, тъй като счупен подпис така или иначе спира инсталирането. Въпросът е на чий подпис избирате да се доверявате оттук нататък. Откраднат ключ за подписване е по-лош от откраднат пакет, защото нападателят продължава да произвежда валидни метаданни дълго след първото лошо издание. Ротацията е единственият ремонт и зависи от това доставчикът да публикува нов ключ по канал, който можете да проверите независимо.

Ето защо идентичността на ключа заслужава същото внимание като URL адреса на хранилището. Ключ, взет от адрес в стар отговор във форум, не доказва нищо за издателя, докато HTTPS защитава преноса до този, който е отговорил на телефона. Сигурността на преноса и идентичността на издателя са различни въпроси и само първият се решава със сертификат.

Ограничете ключа до източника, не до системата

Съвременният APT приема препратка Signed-By, специфична за източника. Управляван от оператора ключ може да живее в /etc/apt/keyrings/, а записът на източника посочва ключа, който може да удостовери този архив. Това е по-тясно от хвърлянето на същия ключ в глобално доверен набор, където той може да гарантира за източници, които никога не сте искали да разрешавате. Следвайте инсталираната версия на APT и актуалните инструкции на доставчика, вместо да смесвате фрагменти от различни поколения ръководства.

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

Никога не поправяйте неуспех на подпис, като изключвате проверката или маркирате неизвестен архив като доверен. Това заменя видима грешка с невидима, а невидимата остава, докато някой не одитира списъка с източници. Ако ключът не съвпада, правилната поправка е да намерите правилния ключ, а не да премахнете проверката.

Вземете подробностите за хранилището и идентичността на ключа от проекта или от управляван администратор. Ключ, копиран от публикация в блог, е твърдение за авторство, не доказателство за него. Когато доставчик публикува канал за ротация, запишете го заедно с ключа, защото точно този канал прави следващата ротация възможна.

Закотвянето на източник не е списък с разрешени пакети

Ограничаването на ключ до един източник ограничава кой архив може да удостовери, а не кои пакети може да публикува този архив. Хранилището може да достави много повече от желания VPN клиент и именно изборът на кандидат и приоритетите на APT решават коя подходяща версия печели. Прегледайте предложената транзакция, преди да я потвърдите, включително списъка със зависимости, защото зависимостите идват от същия архив. Обхватът на ключа не може да изрази ’само този пакет’.

Ако ви трябва по-силен контрол, изразете го като политика върху имената или версиите на пакетите и дръжте тази политика под управление на конфигурацията. Четенето на транзакция отнема минута; откриването на неочакван пакет шест месеца по-късно отнема преглед.

Неочакваните пакети са моментът да спрете, а не да продължите, а въпросът към собственика на архива е защо са необходими. Хранилище, което публикува дузина пакети около един клиент, е нормално за доставчик, който предлага настолен пакет. То е и по-голяма повърхност, отколкото ръководството за инсталиране предполагаше, и точно тази част си струва да се запише. Нито един от двата изхода не е причина да не се доверявате на подписа; и двата са причина да запишете какво сте приели.

Запишете правомощието и как да го премахнете

Запишете собственика на архива, поддържаното издание на операционната система, канала за ротация на ключа и процедурата за премахване. Тези четири факта са това, което наследникът има нужда, когато клиентът се пенсионира или доставчикът смени ключа си. Без тях следващият човек наследява ред за източник и файл с ключ без никаква история.

Премахването е стъпката, която се пропуска, затова я запишете при инсталирането. Изтрийте записа на източника и отделния му ключ заедно и проверете дали този ключ се споменава другаде, преди да изтриете файла. Споделен ключ, изтрит без тази проверка, превръща почистването в несвързано прекъсване, което е най-лошият изход за рутинна промяна. След това потвърдете, че обичайните актуализации все още се разрешават, след като записът е изчезнал.

Едно нещо остава след премахването на хранилището: всеки пакет, вече инсталиран от него, продължава да работи, докато нещо не го замени. Честният въпрос е какво правомощие сте добавили и колко тясно е изразена ролята му.