Aling proseso ng VPN ang tinatamaan ng natuklasang kahinaan?

Ang resulta ng scanner ay nagbabanggit ng address, port at isang bagay na napagkasunduan doon. Hindi nito binabanggit ang prosesong nasa likod ng socket na iyon, at sa isang VPN host maraming proseso ang maaaring maghati sa makina habang isa lamang sa kanila ang tunnel. Ang pagbasa ng version string mula sa side utility o paghahanap ng library file sa disk ay nagdaragdag ng ebidensya tungkol sa host, hindi sa listener. Ang natuklasan ay nagiging aksyunan lamang kapag ikinabit sa isang tumatakbong bahagi at pagkatapos itinugma sa saklaw na aktuwal na isinasaad ng isang abiso.

Mahalaga ang pagkakasunod-sunod: bahagi muna, abiso pangalawa, pagwawasto pangatlo.

Binabanggit ng ulat ang port, hindi programa

Magsimula sa endpoint na aktuwal na tinasa. Sinukat ng isang probe laban sa HTTPS administration port ang web service, ang TLS stack nito at anumang proxy sa harap nito; wala itong natutunan tungkol sa OpenVPN o WireGuard listener sa ibang port. Mas pinalala ito ng mga reverse proxy at management agent, dahil ang certificate at banner ay maaaring pag-aari ng frontend habang ang mahinang library ay nasa likod nito sa isang backend na proseso.

Itala ang destinasyon, transport, port at pangalan ng serbisyo kasama ang resulta upang sumama ang saklaw sa natuklasan.

Ano ba talaga ang tumatakbong build

Sa isang host na pangkalahatan ang gamit, ang naka-install na package at ang na-load na library ay magkaibang tanong. Maaaring maglista ang database ng package ng na-patch na bersyon habang ang matagal nang tumatakbong daemon ay hawak pa rin ang lumang shared object sa memory, at ang bundled na appliance image ay maaaring may sariling mga library na walang package manager ang nag-uulat. Tanungin ang service manager kung ano ang tumatakbo, pagkatapos siyasatin ang proseso at ang mga link nito.

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

Ang oras ng pagsisimula sa listahan ng proseso ay ang detalyeng nilalaktawan ng mga tao. Ang daemon na sinimulan bago ang huling pag-upgrade ng package ay tumatakbo pa rin sa build na na-load nito noong boot, at ito mismo ang kaso kung saan sinasabi ng imbentaryo na na-patch at sinasabi ng socket na iba.

Itugma ang build sa saklaw ng isang abiso

Inilalarawan ng mga abiso ang mga produkto, bersyon at kung minsan ang mga kinakailangang kondisyon, at ang tatlong field na iyon ay hindi laging tumutugma sa bersyon ng package. Ang abiso ng Heartbleed ng OpenVPN noong Abril 2014 ay isang kapaki-pakinabang na makasaysayang halimbawa dahil inihihiwalay nito ang mga apektadong release ng Access Server mula sa mga web service at VPN daemon, na may ibang exposure. Ang aral ay basahin kung aling bahagi ang sakop ng teksto sa halip na itugma ang salitang OpenSSL ayon sa pattern.

Luma na rin ang abisong iyon. Ang mga na-patch na release number nito ay hindi na payo sa pag-install ngayon, at ang depektong naayos noong 2014 ay walang sinasabi tungkol sa mga problemang sumunod sa branch na pinapatakbo mo ngayon.

Ayusin ang hindi pagkakasundo, pagkatapos isara ang exposure

Kapag hindi nagtutugma ang imbentaryo at pagtatasa, tingnan kung inilalarawan ng dalawa ang parehong endpoint at parehong runtime: ibang address, frontend proxy, pangalawang serbisyo, lumang prosesong nakakabit pa rin sa port, o bundled na library na hindi kailanman nakita ng package manager. Ayusin iyon sa hangganan bago muling isulat ang isang ulat.

Ilapat ang sinusuportahang pagwawasto, i-restart ang apektadong serbisyo at kumpirmahin na ang bagong build ang tumatakbo ngayon. Ang na-patch na file sa disk habang ang lumang proseso ay naglilingkod pa rin ng trapiko ay hindi pagwawasto.

Pagkatapos harapin ang maaaring hawakan ng bahagi sa panahon ng exposure window. Ang pag-patch at pagpapalit ng kredensyal ay sumasagot sa magkaibang tanong, at ang certificate na nakaimbak malapit sa apektadong host ay hindi mismo listahan ng tumagas. Sundin ang pamamaraan ng may-ari ng insidente para sa pagpapawalang-bisa, pagtanggal ng session at pag-update ng client, at itala kung aling bahagi ang naapektuhan, bakit angkop ang ebidensya at ano ang nagsara nito. Ang talaang iyon ang babasahin ng susunod na pagsusuri.