Как проверить, что покрывает аварийный выключатель на скомпрометированном хосте

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

Включите аварийный выключатель, отключите туннельный сервер от сети и наблюдайте, что машина всё ещё делает. Тест стоит провести, потому что он отделяет то, что брандмауэр действительно применяет, от того, что вы предполагали, а результаты уже, чем обещают большинство страниц продуктов. Аварийный выключатель управляет сетевыми маршрутами; он не управляет программой, которая уже работает на устройстве. Я выполняю эту последовательность на каждой машине, клиент которой заявляет о 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 и выдержала ли блокировка, когда туннель упал. Вы не можете утверждать, что операционная система чиста, и не можете утверждать, что служба на дальнем конце сохранит вашу учётную запись в тайне.

Держите две проблемы раздельно и дайте каждой собственный контроль:

  • Аварийный выключатель: определённое требование к отказу, подтверждённое тестом обрыва, который вы повторяете после каждого обновления клиента.
  • Доверие к устройству: поддерживаемые обновления, защита конечных точек из надёжного источника, проверка необъяснимых разрешений и запросов аутентификации.
  • Инцидент: при подозрении на компрометацию следуйте процессу платформы или организации; новый сервер не является шагом очистки.
  • Раскрытие: прося помощи, не вставляйте закрытые ключи или целые диагностические архивы, потому что журналы и снимки экрана несут те же секреты, что и соединение.

Выполните последовательность снова после следующего обновления, потому что аварийный выключатель — это конфигурация, которая движется вместе с версиями. Тест — единственное доказательство того, что поведение, на которое вы полагаетесь, всё ещё то, которое вы получаете.

Похожие статьи