Ваш VPN-шлюз скомпрометовано: що насправді розкрито
Зламаний VPN-шлюз бачить усередині свого тунелю, але це не контроль над кожною сесією. Розділіть трафік, доступність і збережені секрети перед відновленням.
VPN-шлюз стоїть на кінці тунелю, який він захищає, тобто він завершує це шифрування, а не пропускає його далі. Якщо зловмисник контролює хост, тунель ззовні все ще виглядає здоровим, а машина посередині більше не заслуговує довіри. Корисне питання не в тому, чи все розшифровується. А в тому, що цей хост міг бачити, куди міг дістатися і які секрети на ньому справді зберігалися. Ці три відповіді сильно різняться, і реакція різниться разом із ними.
Шлюз завершує тунель, тому бачить його зсередини
Шифрування у VPN іде стрибок за стрибком, і шлюз — це стрибок. Він знімає зовнішній шар, застосовує політику і передає внутрішній пакет, тому кожен переносний пакет у якийсь момент існує в читабельній формі в пам'яті цього хоста. Це проєктне рішення, а не дефект. Тому компрометація шлюзу — інша подія, ніж компрометація криптографії тунелю.
Перше, що отримує зловмисник, — це позиція: можливість спостерігати за переносним трафіком, змінювати пересилання або відповідати замість бекенду. Що він отримає далі, залежить від хоста, і тут люди переоцінюють. Лише доступ до шлюзу не передає ключі TLS-сесії браузера, бо їх там ніколи не було.
Три розкриття, які не однакові за розміром
Розділіть питання на переносний трафік, доступні системи та збережені секрети, а потім дайте відповідь на кожне окремо.
| Exposure | What the attacker gains | What does not follow |
|---|---|---|
| Carried traffic | Plaintext of whatever the tunnel forwards without its own encryption | Keys for TLS sessions that terminate at the application |
| Reachable systems | Whatever the backends accept from the gateway's address | Control of every connected client endpoint |
| Stored secrets | The specific keys, tokens and accounts present on that host | Possession of every client certificate or of a CA key |
Середній рядок — той, який пропускають. Шлюз зазвичай має маршрут у приватні мережі та адресу джерела, якій бекенди вже довіряють, тому цікаве питання — що ці бекенди дозволяють з цієї адреси. Вузька політика клієнтського доступу — добрий контроль, але зловмисник на хості не обмежений інтерфейсом, який використав би звичайний клієнт.
Нижній рядок вирішує, скільки триває інцидент. Ключ сервера і ключ CA мають цілком різні радіуси ураження, як і локальний обліковий запис адміністратора та токен моніторингу лише для читання.
HTTPS усередині тунелю залишається HTTPS
TLS застосунку завершується в застосунку, а не на VPN-шлюзі, тому скомпрометований шлюз для цих потоків бачить лише шифротекст. Це реальне обмеження того, що отримує зловмисник, і про це варто сказати прямо, бо протилежне твердження поширює паніку та погані рішення. Дві умови це ламають. Якщо на шляху стоїть компонент інспекції з довіреним сертифікатом, шлюз може за задумом бачити відкритий текст. Якщо сам кінцевий пункт застосунку скомпрометовано, тунель не має значення.
Тому відповідь на питання, що вони бачили, є умовною, і її слід записати як умови, а не оголошувати вироком.
Що має змінитися, перш ніж знову довіряти
Перебудувати хост необхідно і рідко достатньо. Зловмисник, у якого все ще є обліковий запис керування, облікові дані розгортання або ключ підпису, може повернути хост так, як йому треба. Відновлення має починатися з адміністративного шляху, який не залежить від скомпрометованої машини.
Перш ніж вирішувати, що змінювати, складіть опис того, що на ньому було. Ключі, службові облікові записи, токени API, локальні користувачі, заплановані завдання, довірчі зв'язки та конвеєр розгортання — усі кандидати, і в кожного є власник, який має це підтвердити.
ss -lntup
getent passwd
crontab -l
ip route show table allЦей список — найшвидший спосіб побачити, що пропонував хост і куди міг дістатися. Спершу збережіть докази, за процедурою власника реагування, бо перебудова знищує саме те, що потрібно розслідуванню. NIST SP 800-61 Редакція 3 розглядає підготовку, виявлення, реагування та відновлення як частини одного процесу ризику, а не як інструкцію з перезавантаження.
Межі, які роблять наступний випадок дешевшим
Чотири межі варто збудувати до того, як вони знадобляться. Тримайте незалежний шлях відновлення, який не автентифікується через шлюз. Тримайте право підпису окремо від хоста, що обслуговує трафік. Обмежте, куди шлюз може дістатися, щоб скомпрометований шлюз не був автоматично скомпрометованою мережею керування. І записуйте, кому належать кожні облікові дані, щоб ротація була телефонним дзвінком, а не археологічним проєктом.
Жодна з них не запобігає компрометації. Вони її обмежують і створюють різницю між поганим тижнем і поганим кварталом.