Ваш 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 рассматривает подготовку, обнаружение, реагирование и восстановление как части одного процесса риска, а не как инструкцию по перезагрузке.
Границы, которые делают следующий случай дешевле
Четыре границы стоит построить до того, как они понадобятся. Держите независимый путь восстановления, который не аутентифицируется через шлюз. Держите право подписи отдельно от хоста, который обслуживает трафик. Ограничьте, куда шлюз может добраться, чтобы скомпрометированный шлюз не был автоматически скомпрометированной сетью управления. И записывайте, кому принадлежат каждые учётные данные, чтобы ротация была телефонным звонком, а не археологическим проектом.
Ни одна из них не предотвращает компрометацию. Они её ограничивают и создают разницу между плохой неделей и плохим кварталом.