Mihin VPN-prosessiin tuo haavoittuvuushavainto osuu?

Skannerin tulos nimeää osoitteen, portin ja jotain, josta siellä sovittiin. Se ei nimeä prosessia tuon pistokkeen takana, ja VPN-isännässä useat prosessit voivat jakaa koneen, kun vain yksi niistä on tunneli. Versiomerkkijonon lukeminen apuohjelmasta tai kirjastotiedoston löytäminen levyltä lisää todisteita isännästä, ei kuuntelijasta. Havainnosta tulee toimittava vasta, kun se liitetään yhteen käynnissä olevaan komponenttiin ja sovitetaan sitten laajuuteen, jonka neuvo todella ilmoittaa.

Järjestys on tärkeä: ensin komponentti, toiseksi neuvo, kolmanneksi korjaus.

Raportti nimeää portin, ei ohjelmaa

Aloita päätteestä, joka todella arvioitiin. HTTPS-hallintaporttia vastaan tehty koe mittasi verkkopalvelun, sen TLS-pinon ja minkä tahansa edessä olevan välityspalvelimen; se ei oppinut mitään toisessa portissa olevasta OpenVPN- tai WireGuard-kuuntelijasta. Käänteiset välityspalvelimet ja hallinta-agentit pahentavat tätä, koska varmente ja banneri voivat kuulua etuosaan, kun taas haavoittuva kirjasto on sen takana taustaprosessissa.

Kirjaa kohde, kuljetus, portti ja palvelun nimi tuloksen kanssa, jotta laajuus kulkee havainnon mukana.

Mikä käynnissä oleva kooste oikeastaan on

Yleiskäyttöisessä isännässä asennettu paketti ja ladattu kirjasto ovat eri kysymyksiä. Pakettitietokanta voi listata korjatun version, kun pitkään käynnissä oleva taustapalvelu pitää yhä vanhaa jaettua objektia muistissa, ja sulautettu laitekuva voi sisältää omat kirjastonsa, joista mikään paketinhallinta ei raportoi. Kysy palvelunhallinnalta, mitä on käynnissä, ja tutki sitten prosessi ja sen linkitykset.

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

Prosessiluettelon aloitusaika on yksityiskohta, jonka ihmiset ohittavat. Ennen viimeisintä pakettipäivitystä käynnistetty taustapalvelu ajaa yhä käynnistyksessä lataamaansa koostetta, ja juuri siinä tapauksessa inventaario sanoo korjatuksi ja pistoke sanoo muuta.

Koosteen sovittaminen neuvon laajuuteen

Neuvot kuvaavat tuotteita, versioita ja joskus vaadittuja ehtoja, eivätkä nämä kolme kenttää aina vastaa paketin versiota. OpenVPN:n huhtikuun 2014 Heartbleed-neuvo on hyödyllinen historiallinen esimerkki, koska se erottaa vaikutuksen alaiset Access Server -julkaisut verkkopalveluista ja VPN-taustapalveluista, joilla oli erilainen altistus. Oppi on lukea, minkä komponentin teksti kattaa, sen sijaan että OpenSSL-sanaa sovitettaisiin kaavamaisesti.

Tuo neuvokin on vanhentunut. Sen korjatut julkaisunumerot eivät ole nykyään asennusohje, eikä vuonna 2014 korjattu virhe kerro mitään myöhemmistä ongelmista haarassa, jota tänään ajat.

Ristiriidan ratkaiseminen ja sitten altistuksen sulkeminen

Kun inventaario ja arviointi ovat eri mieltä, tarkista, kuvaavatko molemmat samaa päätettä ja suoritusympäristöä: toinen osoite, etuvälityspalvelin, toinen palvelu, vanha prosessi, joka on yhä sidottu porttiin, tai sulautettu kirjasto, jota paketinhallinta ei koskaan nähnyt. Ratkaise se rajalla ennen raportin uudelleenkirjoittamista.

Ota tuettu korjaus käyttöön, käynnistä asianomainen palvelu uudelleen ja varmista, että uusi kooste on nyt käynnissä oleva. Levylle korjattu tiedosto, kun vanha prosessi yhä palvelee liikennettä, ei ole korjaus.

Käsittele sitten se, mitä komponentti on voinut sisältää altistusikkunan aikana. Paikkaaminen ja tunnusten vaihtaminen vastaavat eri kysymyksiin, eikä asianomaisen isännän lähelle tallennettu varmente ole itsessään luettelo siitä, mikä vuoti. Noudata tapahtuman omistajan menettelyä mitätöinnille, istuntojen poistolle ja asiakaspäivityksille ja kirjaa, mikä komponentti oli vaikutuksen alainen, miksi todisteet päivät ja mikä sen sulki. Juuri tuon merkinnän myöhempi tarkastelu lukee.