Cara menguji apa yang dicakup sakelar darurat pada host yang telah disusupi

Jalankan uji pemutusan, baca hasil setiap lapisan, dan lihat di mana sakelar darurat berhenti: ia memblokir jalur, bukan perangkat lunak yang membaca data sebelum enkripsi.

Nyalakan sakelar darurat, matikan server terowongan dari jaringan, dan perhatikan apa yang masih dilakukan mesin. Uji ini layak dijalankan karena memisahkan apa yang benar-benar ditegakkan firewall dari apa yang Anda anggap ditegakkan, dan hasilnya lebih sempit daripada yang disiratkan sebagian besar halaman produk. Sakelar darurat mengatur jalur jaringan; ia tidak mengatur perangkat lunak yang sudah berjalan di perangkat. Saya menjalankan urutan ini pada setiap mesin yang kliennya mengklaim fail-closed, dan butuh sekitar sepuluh menit.

Mulai dari klien, bukan dari server

Titik penegakan adalah host tempat Anda duduk: firewall sistem operasi, layanan pembantu, atau driver klien VPN itu sendiri. Ini penting karena semua yang bisa dilakukan sakelar dibatasi oleh apa yang dilihat lapisan itu. Jika klien menerapkan blokir dengan aturan perutean plus tanda, apa pun dengan hak istimewa yang cukup dapat menambahkan aturannya sendiri; jika memakai tabel firewall kernel, hak istimewa yang sama dapat menyunting tabel. Kekuatan sandi tidak pernah masuk ke pertanyaan ini.

Jadi hal pertama yang harus dipastikan adalah siapa yang memiliki kebijakan di perangkat ini dan apa yang boleh ditimpanya. Pada mesin kerja terkelola jawabannya biasanya agen titik akhir organisasi, dan VPN pribadi tidak menghapus kemampuan itu, bagaimana pun terowongan dikonfigurasi.

Langkah satu: pastikan blokir pada jalur yang Anda yakini tercakup

Putuskan terowongan di ujung jauh, bukan di klien, agar klien tetap percaya bahwa seharusnya terhubung. Lalu coba apa yang benar-benar akan dicoba orang:

curl -m 5 -sS -o /dev/null -w '%{http_code}
' https://example.com
ping -c 2 1.1.1.1
ip route
nft list ruleset   # or: iptables -S

Anda ingin klien yang gagal cepat dan bersih, bukan yang menggantung sampai batas waktu peramban. Menggantung biasanya berarti paket dibuang diam-diam oleh aturan tanpa penolakan, yang dapat diterima, tetapi bisa juga berarti klien meninggalkan rute default usang yang mengarah ke antarmuka mati. Baca tabel perutean saat terowongan terputus: rute default yang masih menunjuk ke perangkat terowongan dan aturan firewall yang hanya memblokir koneksi keluar baru adalah dua keadaan berbeda, dan hanya satu yang fail-closed.

Ulangi perintah yang sama dengan opsi izinkan-LAN klien menyala dan mati. Tombol itu adalah tempat sebagian besar kejutan bersemayam, karena ia membuka kembali jalur yang seharusnya ditutup oleh seluruh kebijakan lainnya.

Langkah dua: periksa DNS dan IPv6 sebagai jalur terpisah

Resolusi nama adalah celah yang bertahan di sebagian besar implementasi, karena kueri bisa keluar melalui sesuatu selain resolver sistem. Bertanyalah dengan alat yang mengabaikan konfigurasi resolver Anda, dan periksa sisi v6 sekaligus:

dig +short example.com
dig +short @1.1.1.1 example.com
curl -6 -m 5 -sS https://example.com -o /dev/null -w '%{http_code}
'
ip -6 route

Jawaban kosong untuk kedua kueri nama saat terowongan terputus adalah hasil yang Anda inginkan. Jika kueri kedua menjawab, alamat resolver yang dikodekan keras dapat dijangkau dan terowongan bukan satu-satunya jalan keluar dari mesin. Jika hanya permintaan v6 yang berhasil, kebijakan mencakup IPv4 dan mengabaikan IPv6, yang merupakan kebocoran yang sama di keluarga alamat lain.

Peramban membuat ini lebih sulit dibaca dari luar, karena peramban yang dikonfigurasi untuk DNS melalui HTTPS menyelesaikan kueri lewat permintaan HTTPS: kueri hanya terblokir sejauh port 443 ke titik akhir itu terblokir. Pada host yang kebijakannya mengizinkan subnet lokal, permintaan itu masih bisa mencapai resolver di LAN.

Langkah tiga: pisahkan paparan jaringan dari paparan titik akhir

Sekarang bagian yang tidak terjangkau aturan firewall mana pun. Sakelar darurat memblokir jalur keluar dari mesin; ia tidak menghentikan perangkat lunak di mesin membaca data sebelum dienkripsi, dan tidak menghentikan perangkat lunak itu memakai terowongan secara sah. Keylogger, ekstensi berbahaya, layar yang dibiarkan tak terkunci, klien sinkronisasi dengan izin luas: semuanya memindahkan informasi lewat koneksi yang dengan senang hati diizinkan sakelar.

Hal yang sama berlaku untuk perangkat lunak pemantau yang sengaja dipasang pemberi kerja. Memblokir rute tidak menghapusnya, dan membeli server VPN baru bukan perbaikannya, karena paparan berada di hulu terowongan.

Pengelola papan klip yang mengunggah ke akun cloud menunjukkan hal itu dengan tajam. Lalu lintasnya terenkripsi, tujuannya diizinkan, dan sakelar darurat melaporkan keadaan sehat sepanjang waktu.

Langkah empat: tulis klaim yang didukung uji Anda

Setelah uji pemutusan Anda dapat menyatakan fakta spesifik: aplikasi mana yang gagal, jalur mana yang berhenti, bagaimana DNS dan IPv6 berperilaku, dan apakah blokir bertahan saat terowongan jatuh. Anda tidak dapat menyatakan bahwa sistem operasi bersih, dan tidak dapat menyatakan bahwa layanan di ujung jauh akan menjaga login Anda tetap privat.

Jaga kedua masalah tetap terpisah dan beri masing-masing kendalinya sendiri:

  • Sakelar darurat: persyaratan kegagalan yang ditetapkan, diverifikasi oleh uji pemutusan yang Anda ulangi setelah setiap peningkatan klien.
  • Kepercayaan perangkat: pembaruan yang didukung, perlindungan titik akhir dari sumber tepercaya, peninjauan izin dan permintaan autentikasi yang tidak dijelaskan.
  • Insiden: ikuti proses platform atau organisasi saat penyusupan dicurigai; server baru bukan langkah pembersihan.
  • Pengungkapan: saat meminta bantuan, jangan menempelkan kunci privat atau arsip diagnostik lengkap, karena log dan tangkapan layar membawa rahasia yang sama dengan koneksi.

Jalankan urutan lagi setelah pembaruan berikutnya, karena sakelar darurat adalah konfigurasi yang bergerak bersama versi. Uji itu adalah satu-satunya bukti bahwa perilaku yang Anda andalkan masih perilaku yang Anda dapatkan.

Artikel terkait