Якого процесу 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 року, нічого не говорить про пізніші проблеми в гілці, яку ви використовуєте сьогодні.

Розв’язання розбіжності, потім закриття експозиції

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

Застосуйте підтримуване виправлення, перезапустіть уражену службу й підтвердьте, що тепер працює саме нова збірка. Виправлений файл на диску, поки старий процес усе ще обслуговує трафік, — це не усунення.

Потім розгляньте те, що компонент міг зберігати протягом вікна експозиції. Виправлення й заміна облікових даних відповідають на різні питання, а сертифікат, збережений поблизу ураженого хоста, сам по собі не є списком того, що витекло. Дотримуйтеся процедури власника інциденту щодо відкликання, видалення сеансів і оновлення клієнтів та зафіксуйте, який компонент був уражений, чому докази застосовні та що його закрило. Саме цей запис прочитає пізніша перевірка.