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

Міф: один контроль покриває весь ризик

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

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

Їхнє розділення також говорить, який ризик ви вирішили прийняти. Більшість реальних рішень пом'якшують одну межу й терплять іншу, і це нормально, поки запис про зміну каже, яка з них яка.

До чого віддалений вузол справді може дістатися

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

ss -tulpn
sudo nft list ruleset
ip -br addr

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

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

Архітектура нульової довіри NIST формулює принцип, що стоїть за всім цим: лише мережеве розташування не дає неявної довіри. Автентифікація ресурсів і далі має роботу після допуску тунелю, як і питання про те, хто ще ділить цю мережу.

Що може бачити оператор на шляху

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

Зберігайте звичайну перевірку сертифікатів для реального призначення й розумійте шлях розв'язувача та метаданих, бо запит DNS може розкрити більше, ніж корисне навантаження перед ним. Самі метадані, тобто до яких адрес і коли ви зверталися, часто відповідають на питання оператора без будь-якої потреби читати вміст. Тому «трафік зашифровано» і «трафік приватний» — різні твердження.

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

Що дозволено змінювати локальному клієнту

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

getcap /usr/sbin/openvpn
systemd-analyze security vpn-client.service
ip netns list

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

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

Запишіть, яку межу ви прийняли

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

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

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

Схожі статті