Proses VPN mana yang terkena temuan kerentanan itu?

Hasil pemindai menyebutkan sebuah alamat, port, dan sesuatu yang dinegosiasikan di sana. Hasil itu tidak menyebut proses di balik soket tersebut, dan pada host VPN beberapa proses dapat berbagi mesin sementara hanya satu di antaranya yang merupakan terowongan. Membaca string versi dari utilitas sampingan atau menemukan berkas pustaka di disk menambah bukti tentang host, bukan tentang pendengar. Temuan baru dapat ditindaklanjuti ketika ditempelkan pada satu komponen yang berjalan lalu dicocokkan dengan cakupan yang benar-benar dinyatakan sebuah nasihat.

Urutannya penting: komponen dulu, nasihat kedua, perbaikan ketiga.

Laporan menyebut port, bukan program

Mulailah dari titik akhir yang benar-benar dinilai. Uji terhadap port administrasi HTTPS mengukur layanan web, tumpukan TLS-nya, dan proksi apa pun di depannya; uji itu tidak mempelajari apa pun tentang pendengar OpenVPN atau WireGuard di port lain. Proksi terbalik dan agen manajemen memperburuknya, karena sertifikat dan banner bisa milik bagian depan sementara pustaka rentan berada di belakangnya dalam proses backend.

Catat tujuan, transportasi, port, dan nama layanan bersama hasilnya agar cakupan ikut bergerak bersama temuan.

Apa sebenarnya build yang sedang berjalan

Pada host serbaguna, paket yang terpasang dan pustaka yang dimuat adalah dua pertanyaan terpisah. Basis data paket dapat mencantumkan versi yang ditambal sementara daemon yang berjalan lama masih menyimpan objek bersama lama di memori, dan image perangkat terpaket dapat membawa pustaka sendiri yang tidak dilaporkan manajer paket mana pun. Tanyakan kepada manajer layanan apa yang berjalan, lalu periksa proses dan keterkaitannya.

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

Waktu mulai dalam daftar proses adalah detail yang dilewatkan orang. Daemon yang dimulai sebelum pembaruan paket terakhir masih menjalankan build yang dimuatnya saat boot, dan itulah tepat kasus ketika inventaris mengatakan sudah ditambal dan soket mengatakan sebaliknya.

Mencocokkan build dengan cakupan nasihat

Nasihat menjelaskan produk, versi, dan kadang-kadang kondisi yang diperlukan, dan ketiga bidang itu tidak selalu sejajar dengan versi paket. Nasihat Heartbleed OpenVPN April 2014 adalah contoh historis yang berguna karena memisahkan rilis Access Server yang terdampak dari layanan web dan daemon VPN, yang paparannya berbeda. Pelajarannya adalah membaca komponen mana yang dicakup teks itu alih-alih mencocokkan kata OpenSSL berdasarkan pola.

Nasihat itu juga sudah usang. Nomor rilis yang ditambal bukan lagi saran pemasangan sekarang, dan cacat yang diperbaiki pada 2014 tidak mengatakan apa pun tentang masalah berikutnya di cabang yang Anda jalankan hari ini.

Menyelesaikan perselisihan, lalu menutup paparan

Ketika inventaris dan penilaian berbeda, periksa apakah keduanya menjelaskan titik akhir dan runtime yang sama: alamat lain, proksi front-end, layanan kedua, proses lama yang masih terikat ke port, atau pustaka terpaket yang tidak pernah dilihat manajer paket. Selesaikan itu di batas sebelum menulis ulang laporan.

Terapkan koreksi yang didukung, mulai ulang layanan yang terdampak, dan pastikan build baru itulah yang sekarang berjalan. Berkas yang ditambal di disk sementara proses lama masih melayani lalu lintas bukan perbaikan.

Lalu tangani apa yang mungkin disimpan komponen selama jendela paparan. Menambal dan mengganti kredensial menjawab pertanyaan berbeda, dan sertifikat yang disimpan dekat host terdampak bukanlah daftar apa yang bocor. Ikuti prosedur pemilik insiden untuk pencabutan, penghapusan sesi, dan pembaruan klien, dan catat komponen mana yang terdampak, mengapa buktinya berlaku, dan apa yang menutupnya. Catatan itulah yang akan dibaca tinjauan berikutnya.