Як перевірити, що покриває аварійний вимикач на скомпрометованому хості

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

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

Починайте з клієнта, а не з сервера

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

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

Перший крок: підтвердьте блокування на шляхах, які, на вашу думку, він покриває

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

curl -m 5 -sS -o /dev/null -w '%{http_code}
' https://example.com
ping -c 2 1.1.1.1
ip route
nft list ruleset   # or: iptables -S

Вам потрібен клієнт, який швидко й чисто відмовляє, а не той, що висить до тайм-ауту браузера. Зависання зазвичай означає, що пакети тихо відкидаються правилом без відмови, що прийнятно, але може також означати, що клієнт залишив застарілий маршрут за замовчуванням у мертвий інтерфейс. Прочитайте таблицю маршрутизації при опущеному тунелі: маршрут за замовчуванням, що досі вказує на тунельний пристрій, і правило брандмауера, яке блокує лише нові вихідні з'єднання, — два різні стани, і лише один із них fail-closed.

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

Другий крок: перевірте DNS і IPv6 як окремі шляхи

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

dig +short example.com
dig +short @1.1.1.1 example.com
curl -6 -m 5 -sS https://example.com -o /dev/null -w '%{http_code}
'
ip -6 route

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

Браузери ускладнюють читання ззовні, бо браузер, налаштований на DNS через HTTPS, розв'язує запит через HTTPS-запит: запит блокується лише настільки, наскільки заблокований порт 443 до цієї кінцевої точки. На хості, де політика дозволяє локальну підмережу, цей запит усе ще може дістатися резолвера в LAN.

Третій крок: відокремте мережеву експозицію від експозиції кінцевих точок

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

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

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

Четвертий крок: сформулюйте твердження, яке підтверджує ваш тест

Після тесту обриву ви можете назвати конкретні факти: які застосунки відмовили, які шляхи зупинилися, як поводилися DNS і IPv6 і чи витримало блокування, коли тунель упав. Ви не можете стверджувати, що операційна система чиста, і не можете стверджувати, що служба на далекому кінці збереже ваш вхід у таємниці.

Тримайте дві проблеми окремо і дайте кожній власний контроль:

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

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

Схожі статті