OpenConnect csd-wrapper: перевірте скрипт перед входом

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

Крок 1: Знайдіть етап, що не вдався

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

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

openconnect --version
openconnect --verbose --user="$VPN_USER" vpn.example.com </dev/null

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

Крок 2: Прочитайте скрипт до того, як він потрапить у профіль

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

sha256sum ./vpn-csd-wrapper.sh
bash -n ./vpn-csd-wrapper.sh

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

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

grep -nE 'base64 -d|xxd -r|eval |curl |wget ' ./vpn-csd-wrapper.sh

Крок 3: Виберіть ідентичність, від якої працює обгортка

--csd-user знижує привілеї, поки виконується програма CSD, TNCC або HIP. Цей обліковий запис — частина локального порядку виконання, а не ім’я користувача, що передається шлюзу.

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

sudo -u vpn-csd /usr/local/libexec/vpn-csd-wrapper.sh

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

Крок 4: Збережіть зміну зворотною

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

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

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

Короткі шляхи, що створюють другу проблему

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

Вимкнення перевірки сервера, повторне відтворення старого cookie і нагромадження неперевірених скриптів — усе це міняє видиму невдачу на невидиму. Якщо встановлений клієнт не може завершити підтримуваний потік, попросіть схвалену альтернативу замість того, щоб вигинати наявну.

Посібник OpenConnect описує --csd-wrapper і --csd-user окремо, і це та підказка, яка важлива: скрипт та ідентичність — два рішення. Перегляньте їх окремо і запишіть обидва. Тоді запрошення до входу перестає бути загадкою, яку ви розв’язуєте вставленням коду.