Кой 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 година, не казва нищо за по-късни проблеми в клона, който използвате днес.

Разрешаване на разногласието, после затваряне на излагането

Когато инвентарът и оценката се разминават, проверете дали и двете описват една и съща крайна точка и среда на изпълнение: друг адрес, предно прокси, втора услуга, стар процес, все още вързан към порта, или вградена библиотека, която мениджърът на пакети никога не е виждал. Изяснете това на границата, преди да пренапишете доклад.

Приложете поддържаната корекция, рестартирайте засегнатата услуга и потвърдете, че новата компилация е тази, която работи сега. Коригиран файл на диска, докато старият процес все още обслужва трафик, не е отстраняване.

След това се заемете с това, което компонентът е могъл да съдържа през прозореца на излагане. Корекцията и подмяната на идентификационни данни отговарят на различни въпроси, а сертификат, съхраняван близо до засегнатия хост, сам по себе си не е списък на изтеклото. Следвайте процедурата на собственика на инцидента за отнемане, премахване на сесии и обновяване на клиенти и запишете кой компонент е бил засегнат, защо доказателствата са се прилагали и какво го е затворило. Този запис е това, което ще прочете по-късен преглед.