Джерело 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 вирішують, яка придатна версія переможе. Перегляньте запропоновану транзакцію до підтвердження, включно зі списком залежностей, бо залежності надходять з того самого архіву. Обсяг ключа не може виразити «лише цей пакет».

Якщо потрібен суворіший контроль, виразіть його як політику щодо назв або версій пакетів і тримайте цю політику під керуванням конфігурацією. Читання транзакції займає хвилину; виявлення неочікуваного пакета за пів року займає перевірку.

Неочікувані пакети — це момент зупинитися, а не продовжувати, і питання до власника архіву — чому вони потрібні. Репозиторій, що публікує дюжину пакетів навколо одного клієнта, нормальний для постачальника, який випускає настільний пакет. Це також більша поверхня, ніж припускав посібник зі встановлення, і саме цю частину варто записати. Жоден із двох результатів не є причиною не довіряти підпису; обидва — причина записати, що ви прийняли.

Запишіть повноваження та спосіб його видалення

Запишіть власника архіву, підтримуваний випуск операційної системи, канал зміни ключа та процедуру видалення. Ці чотири факти потрібні наступникові, коли клієнт знімається з експлуатації або постачальник змінює свій ключ. Без них наступна людина успадковує рядок джерела й файл ключа без жодної історії.

Видалення — це крок, який пропускають, тому запишіть його під час встановлення. Видаліть запис джерела та його виділений ключ разом і перевірте, чи не згадується цей ключ десь інде, перш ніж прибирати файл. Спільний ключ, видалений без такої перевірки, перетворює прибирання на не пов’язаний збій, а це найгірший результат для рутинної зміни. Потім підтвердьте, що звичайні оновлення все ще розв’язуються після зникнення запису.

Одне залишається після видалення репозиторію: будь-який уже встановлений з нього пакет продовжує працювати, доки щось його не замінить. Чесне питання — які повноваження ви додали і наскільки вузько було виражено їхню роль.