Какого процесса VPN касается этот результат сканирования уязвимости?

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

Порядок важен: сначала компонент, затем рекомендация, затем устранение.

Отчёт называет порт, а не программу

Начните с конечной точки, которая действительно оценивалась. Проверка административного порта HTTPS измерила веб-службу, её стек TLS и любой прокси перед ней; о слушателе OpenVPN или WireGuard на другом порту она не узнала ничего. Обратные прокси и агенты управления ухудшают ситуацию, потому что сертификат и баннер могут принадлежать фронтенду, а уязвимая библиотека находится позади, в процессе бэкенда.

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

Что на самом деле представляет собой работающая сборка

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

systemctl status openvpn-server@server --no-pager
ps -o pid,lstart,args -C openvpn
ss -lntup | grep -E '1194|443'
dpkg -l | grep -i -E 'openvpn|libssl'
ldd "$(command -v openvpn)" | grep -i ssl

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

Сопоставление сборки с областью действия рекомендации

Рекомендации описывают продукты, версии и иногда обязательные условия, и эти три поля не всегда совпадают с версией пакета. Рекомендация OpenVPN по Heartbleed от апреля 2014 года — полезный исторический пример, потому что она отделяет затронутые выпуски Access Server от веб-служб и демонов VPN, у которых была разная подверженность. Урок в том, чтобы читать, какой компонент охватывает текст, а не сопоставлять слово OpenSSL по шаблону.

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

Разрешение разногласия, затем закрытие подверженности

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

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

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