Сканер отмечает CVE-2019-14899 на машине, которая годами использует VPN, и первая реакция — объявить VPN сломанным. Это неверная рамка. Раскрытая проблема касается злоумышленника в локальной сети жертвы, который делает выводы о некоторых соединениях TCP, а не сайта, расшифровывающего ваш туннель.

Пройдите четыре проверки ниже по порядку. Каждая либо сужает проблему, либо завершает расследование.

Проверка 1: охватывает ли бюллетень ваше ядро

Ищите собственную запись вашего дистрибутива, а не пересказ даты выпуска из блога. Страница безопасности Ubuntu для этой CVE перечисляет общий пакет linux для 18.04 LTS как уязвимый с отложенным исправлением и отслеживает другие пакеты ядра отдельными строками. Сопоставьте работающий выпуск и пакет ядра с нужной строкой. Знакомый на вид номер версии — не совпадение.

Результат сканера означает, что идентификатор относится к чему-то в вашей инвентаризации. Он не означает, что соседнее устройство использовало машину.

Проверка 2: кто злоумышленник в модели

Модель угроз предполагает соседнего злоумышленника, который может взаимодействовать с сетью доступа жертвы. Это конкретная позиция, а не произвольный удалённый сервис, которому не нравится ваша точка выхода. Если пользователи подключаются из кафе, допущение реалистично; если они за управляемой корпоративной локальной сетью, это другой разговор.

Оставляйте открытым вопрос о доверии к локальной сети, даже когда туннель зашифрован. Шифрование отвечает на другой вопрос, чем соседство.

Проверка 3: на какой уровень вы полагаетесь

Правильно проверенный HTTPS даёт собственную защиту записей приложения, а TLS 1.3 аутентифицирует эти данные от конца до конца. Но он не обещает, что злоумышленник не может прервать нижележащее соединение TCP. Поэтому приложение может быть безопасным для чтения и при этом прерываемым, а прерывание — не тот же результат, что раскрытие. Разделите эти два понятия до оценки риска.

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

Проверка 4: какую меру вы действительно внедрили

Раскрытие обсуждает меры маршрутизации и фильтрации и прямо говорит об их пределах, включая фильтрацию обратного пути и асимметричные маршруты. Не копируйте одно значение sysctl на каждый хост VPN и не называйте это исправлением. Фильтрация обратного пути взаимодействует с маршрутизацией, поэтому значение, помогающее одной топологии, может сломать другую.

Проверка — это команда, а не галочка. sysctl net.ipv4.conf.all.rp_filter показывает глобальное значение, а sysctl net.ipv4.conf.tun0.rp_filter показывает значение для интерфейса, которое действительно действует. Прочитайте оба до и после любого изменения.

Используйте рекомендации дистрибутива и собственный дизайн маршрутизации, затем подтвердите настройку на интерфейсе, который несёт туннель, а не в файле, который никто не загрузил.

Что записать

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

Дата выпуска ОС и работающее подключение VPN — не оценка. Это два факта, которые случайно легко собрать.

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