Kurį VPN procesą paliečia tas pažeidžiamumo radinys?

Skaitytuvo rezultatas nurodo adresą, prievadą ir tai, dėl ko ten buvo susitarta. Jis nenurodo proceso, esančio už to lizdo, o VPN mazge keli procesai gali dalytis mašina, nors tik vienas jų yra tunelis. Versijos eilutės skaitymas iš pagalbinės priemonės ar bibliotekos failo radimas diske prideda įrodymų apie mazgą, o ne apie klausytoją. Radinys tampa veiksmingas tik tada, kai jis pririšamas prie vieno veikiančio komponento ir po to suderinamas su apimtimi, kurią pranešimas iš tikrųjų nurodo.

Tvarka svarbi: pirmiausia komponentas, antra – pranešimas, trečia – taisymas.

Ataskaita nurodo prievadą, o ne programą

Pradėkite nuo galinio taško, kuris iš tikrųjų buvo įvertintas. Patikra prieš HTTPS administravimo prievadą išmatavo žiniatinklio paslaugą, jos TLS kamina ir bet kokį priešais esantį tarpinį serverį; ji nieko nesužinojo apie OpenVPN ar WireGuard klausytoją kitame prievade. Atvirkštiniai tarpiniai serveriai ir valdymo agentai tai dar labiau blogina, nes sertifikatas ir banneris gali priklausyti priekinei daliai, o pažeidžiama biblioteka yra už jos, foniniame procese.

Užrašykite paskirties vietą, transportavimą, prievadą ir paslaugos pavadinimą kartu su rezultatu, kad apimtis keliautų kartu su radiniu.

Kas iš tikrųjų yra veikianti versija

Bendros paskirties mazge įdiegtas paketas ir įkelta biblioteka yra atskiri klausimai. Paketų duomenų bazė gali rodyti pataisytą versiją, o ilgai veikiantis demonas vis dar laiko seną bendrinamą objektą atmintyje, ir įtaisytas prietaiso atvaizdas gali turėti savo bibliotekas, apie kurias nepraneša jokia paketų tvarkyklė. Paklauskite paslaugų tvarkyklės, kas veikia, tada patikrinkite procesą ir jo sąsajas.

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

Paleidimo laikas procesų sąraše yra detalė, kurią žmonės praleidžia. Demonas, paleistas prieš paskutinį paketų atnaujinimą, vis dar vykdo versiją, kurią įkėlė paleidžiant, ir būtent tai yra atvejis, kai inventorius sako pataisyta, o lizdas sako ką kita.

Versijos suderinimas su pranešimo apimtimi

Pranešimai aprašo produktus, versijas ir kartais būtinas sąlygas, ir šie trys laukai ne visada sutampa su paketo versija. OpenVPN 2014 metų balandžio Heartbleed pranešimas yra naudingas istorinis pavyzdys, nes jis atskiria paveiktas Access Server laidas nuo žiniatinklio paslaugų ir VPN demonų, kurie turėjo skirtingą poveikį. Pamoka – skaityti, kurį komponentą apima tekstas, o ne lyginti žodį OpenSSL pagal šabloną.

Tas pranešimas taip pat pasenęs. Jo pataisyti laidų numeriai dabar nėra diegimo patarimas, o 2014 metais ištaisyta klaida nieko nesako apie vėlesnes problemas šakoje, kurią šiandien naudojate.

Nesutarimo sprendimas, tada poveikio uždarymas

Kai inventorius ir vertinimas nesutampa, patikrinkite, ar abu aprašo tą patį galinį tašką ir tą pačią vykdymo aplinką: kitą adresą, priekinį tarpinį serverį, antrą paslaugą, seną procesą, vis dar susietą su prievadu, ar įtaisytą biblioteką, kurios paketų tvarkyklė niekada nematė. Išspręskite tai prie ribos, prieš perrašydami ataskaitą.

Taikykite palaikomą pataisą, paleiskite iš naujo paveiktą paslaugą ir patvirtinkite, kad nauja versija dabar veikia. Pataisytas failas diske, o senas procesas vis dar aptarnauja srautą, nėra taisymas.

Tada tvarkykite tai, ką komponentas galėjo saugoti poveikio laikotarpiu. Taisymas ir prisijungimo duomenų pakeitimas atsako į skirtingus klausimus, o prie paveikto mazgo saugomas sertifikatas pats savaime nėra nutekėjusio sąrašas. Vykdykite incidento savininko procedūrą dėl atšaukimo, sesijų šalinimo ir klientų atnaujinimų, ir užrašykite, kuris komponentas buvo paveiktas, kodėl įrodymai tiko ir kas jį uždarė. Tą įrašą skaitys vėlesnė peržiūra.