Kiun VPN-procezon trafas tiu vundebleca trovo?

Skana rezulto nomas adreson, pordon kaj ion, pri kio oni interkonsentis tie. Ĝi ne nomas la procezon malantaŭ tiu ingo, kaj sur VPN-gastiganto pluraj procezoj povas dividi la maŝinon dum nur unu el ili estas la tunelo. Legi versian ĉenon el flanka ilo aŭ trovi bibliotekan dosieron sur la disko aldonas pruvojn pri la gastiganto, ne pri la aŭskultanto. La trovo fariĝas agebla nur kiam ĝi estas ligita al unu ruliĝanta komponanto kaj poste kongruigita kun la amplekso, kiun averto efektive deklaras.

La ordo gravas: unue la komponanto, due la averto, trie la riparo.

La raporto nomas pordon, ne programon

Komencu ĉe la finpunkto, kiu estis efektive taksita. Sondo kontraŭ la HTTPS-administra pordo mezuris la retservon, ĝian TLS-stakon kaj ajnan prokurilon antaŭ ĝi; ĝi lernis nenion pri la OpenVPN aŭ WireGuard aŭskultanto sur alia pordo. Inversaj prokuriloj kaj administraj agentoj plimalbonigas tion, ĉar la atestilo kaj la banner povas aparteni al la antaŭo dum la vundebla biblioteko sidas malantaŭ ĝi en fona procezo.

Registru la celon, transporton, pordon kaj servan nomon kune kun la rezulto, por ke la amplekso vojaĝu kun la trovo.

Kio efektive estas la ruliĝanta konstruo

Sur ĝenerala gastiganto, la instalita pako kaj la ŝarĝita biblioteko estas apartaj demandoj. Pakdatumbazo povas listigi flikitan version dum longdaŭra demono ankoraŭ tenas la malnovan kunhavatan objekton en la memoro, kaj enkonstruita aparata bildo povas porti proprajn bibliotekojn, kiujn neniu paka administranto raportas. Demandu la servan administranton, kio ruliĝas, poste inspektu la procezon kaj ĝiajn ligojn.

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

La komenca tempo en la proceza listo estas la detalo, kiun homoj preterlasas. Demonon startigita antaŭ la lasta paka ĝisdatigo ankoraŭ rulas la konstruon, kiun ĝi ŝarĝis ĉe la ekfunkciigo, kaj tio estas ĝuste la kazo, kiam inventaro diras riparita kaj la ingo diras alie.

Kongruigi la konstruon kun la amplekso de averto

Avertoj priskribas produktojn, versiojn kaj foje postulatajn kondiĉojn, kaj tiuj tri kampoj ne ĉiam kongruas kun paka versio. La Heartbleed-averto de OpenVPN el aprilo 2014 estas utila historia ekzemplo, ĉar ĝi apartigas la tuŝitajn eldonojn de Access Server de la retservoj kaj la VPN-demono, kiuj havis malsaman eksponiĝon. La leciono estas legi, kiun komponanton la teksto kovras, anstataŭ ŝablon-kongruigi la vorton OpenSSL.

Tiu averto ankaŭ estas malnova. Ĝiaj flikitaj eldonaj numeroj nun ne estas instala konsilo, kaj problemo riparita en 2014 diras nenion pri postaj aferoj en la branĉo, kiun vi rulas hodiaŭ.

Solvi la malkonsenton, poste fermi la eksponiĝon

Kiam inventaro kaj taksado malkongruas, kontrolu ĉu ambaŭ priskribas la saman finpunkton kaj rulmedianon: alia adreso, antaŭa prokurilo, dua servo, malnova procezo ankoraŭ ligita al la pordo, aŭ enkonstruita biblioteko, kiun la paka administranto neniam vidis. Solvu tion ĉe la limo antaŭ ol reverki raporton.

Apliku la subtenatan korekton, restartigu la tuŝitan servon kaj konfirmu, ke la nova konstruo estas la nun ruliĝanta. Flikita dosiero sur la disko dum la malnova procezo ankoraŭ servas trafikon ne estas riparo.

Poste traktu tion, kion la komponanto povus esti teninta dum la eksponiĝa fenestro. Flikado kaj anstataŭigo de akreditaĵoj respondas al malsamaj demandoj, kaj atestilo konservita proksime al la tuŝita gastiganto ne estas per si mem listo de tio, kio likis. Sekvu la proceduron de la posedanto de la incidento por revoko, forigo de sesioj kaj klientaj ĝisdatigoj, kaj registru, kiu komponanto estis tuŝita, kial la pruvoj aplikiĝis kaj kio fermis ĝin. Tiu registro estas tio, kion legos posta revizio.