Ваш ключ VPN доступний усім: що виправити

Перша ознака — зазвичай попередження, а не збій. Клієнт відмовляється завантажити ключ, бо файл доступний для читання групі або всім, або перевірка безпеки знаходить client.key з режимом 644 у каталозі профілю, де також лежать експортовані пакети. Поки нічого не зламалося, і саме тому попередження ігнорують. Ключ працює, тунель піднімається, а файл може прочитати будь-який обліковий запис на машині.

Симптом — попередження про права, а не відмова

У Unix-подібній системі приватний ключ має бути доступним лише обліковому запису, що запускає службу. Режим 600 із правильним власником — звична практика. Режим 644 означає, що будь-який локальний користувач може скопіювати ключ, а на спільному складальному хості це реальна аудиторія.

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

Узгодьте режим з ідентичністю служби

Доступ лише для власника пасує ключу, яким користується цей власник. Службі з навмисно спільною групою може знадобитися інша контрольована схема, наприклад читання групою ключа, що належить службовому обліковому запису. Сліпе встановлення одного числового режиму для всіх файлів ламає підтримуваних клієнтів, а chmod -R 777 не вирішує нічого.

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

ls -l /etc/openvpn/client/
stat -c '%U %G %a %n' /etc/openvpn/client/*.key
id openvpn

На інших платформах використовуйте задокументоване сховище ключів або модель керування доступом, а не перекладайте Unix-режими у здогад. Ім'я файлу, що закінчується на private, — це позначка, а не механізм примусу.

Знайдіть копії, які не охоплює режим

Редактори, архіви резервних копій, експортовані профілі та тимчасові пакети можуть кожен зберегти ту саму ідентичність. Захищайте ці копії за їхнім вмістом, бо посилення оригінального файлу нічого не робить для копії в архіві за минулий місяць.

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

Шукайте копії, перш ніж оголосити роботу виконаною: grep -rl рядок заголовка ключа в імовірних каталогах і погляд на винятки резервного копіювання. Результат зазвичай цікавіший за файл, з якого ви почали.

Після виправлення перевірте та замініть

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

Якщо ключ було розкрито, посильте режим, потім замініть облікові дані та відкличте старі. Специфікація POSIX chmod пояснює, що означає кожен біт режиму, і це варто знати до того, як наступна перевірка попросить вас обґрунтувати обране число.