Který proces VPN se týká tento nález zranitelnosti?
Banner, název souboru knihovny a běžící proces mohou popisovat různé věci. Dohledejte nález k jedné komponentě a pak ho porovnejte s rozsahem doporučení.
Výsledek skeneru uvádí adresu, port a něco, co se tam dohodlo. Neuvádí proces za tímto socketem a na hostiteli VPN může několik procesů sdílet stroj, zatímco jen jeden z nich je tunel. Čtení verze z pomocného nástroje nebo nalezení souboru knihovny na disku přidává důkaz o hostiteli, ne o naslouchajícím procesu. Nález je použitelný teprve tehdy, když se připojí k jedné běžící komponentě a poté se porovná s rozsahem, který doporučení skutečně uvádí.
Na pořadí záleží: nejdřív komponenta, potom doporučení, nakonec náprava.
Zpráva uvádí port, ne program
Začněte u koncového bodu, který byl skutečně posouzen. Sonda proti administrativnímu portu HTTPS změřila webovou službu, její TLS stack a případný proxy před ní; o naslouchajícím procesu OpenVPN nebo WireGuard na jiném portu se nedozvěděla nic. Reverzní proxy a správcovští agenti to zhoršují, protože certifikát a banner mohou patřit frontě, zatímco zranitelná knihovna sedí za ní v procesu na pozadí.
Zaznamenejte cíl, transport, port a název služby spolu s výsledkem, aby rozsah putoval s nálezem.
Co je skutečně běžící sestavení
Na hostiteli pro obecné použití jsou nainstalovaný balíček a načtená knihovna oddělené otázky. Databáze balíčků může uvádět opravenou verzi, zatímco dlouho běžící démon stále drží starý sdílený objekt namapovaný v paměti, a vestavěný obraz zařízení může nést vlastní knihovny, které žádný správce balíčků nehlásí. Zeptejte se správce služeb, co běží, a potom prozkoumejte proces a jeho vazby.
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
Čas spuštění v seznamu procesů je detail, který lidé přeskakují. Démon spuštěný před poslední aktualizací balíčků stále běží se sestavením, které načetl při startu, a to je přesně případ, kdy inventář říká opraveno a socket říká opak.
Srovnání sestavení s rozsahem doporučení
Doporučení popisují produkty, verze a někdy požadované podmínky a tato tři pole se ne vždy shodují s verzí balíčku. Doporučení OpenVPN k Heartbleed z dubna 2014 je užitečný historický příklad, protože odděluje postižená vydání Access Serveru od webových služeb a démonů VPN, které měly jinou expozici. Ponaučení je číst, kterou komponentu text pokrývá, místo porovnávání slova OpenSSL podle vzoru.
Toto doporučení je také zastaralé. Jeho opravená čísla vydání už nejsou instalační radou a chyba opravená v roce 2014 nic neříká o pozdějších problémech ve větvi, kterou dnes provozujete.
Vyřešení rozporu a uzavření expozice
Když se inventář a posouzení rozcházejí, zkontrolujte, zda oba popisují stejný koncový bod a běhové prostředí: jinou adresu, frontový proxy, druhou službu, starý proces stále vázaný na port nebo vestavěnou knihovnu, kterou správce balíčků nikdy neviděl. Vyřešte to na hranici, než přepíšete zprávu.
Použijte podporovanou opravu, restartujte postiženou službu a potvrďte, že nyní běží nové sestavení. Opravený soubor na disku, zatímco starý proces stále obsluhuje provoz, není náprava.
Potom se zabývejte tím, co komponenta mohla obsahovat během okna expozice. Záplatování a výměna pověření odpovídají na různé otázky a certifikát uložený blízko postiženého hostitele sám o sobě není seznamem toho, co uniklo. Postupujte podle postupu vlastníka incidentu pro odvolání, odstranění relací a aktualizace klientů a zaznamenejte, která komponenta byla postižena, proč se důkazy vztahovaly a co to uzavřelo. Tento záznam bude číst pozdější revize.