Cara menguji apa yang dilindungi suis maut pada hos yang telah diceroboh

Hidupkan suis maut, putuskan sambungan pelayan terowong dan perhatikan apa yang mesin masih lakukan. Ujian ini berbaloi kerana ia memisahkan apa yang benar-benar dikuatkuasakan oleh tembok api daripada apa yang anda anggap, dan hasilnya lebih sempit daripada yang disarankan oleh kebanyakan halaman produk. Suis maut mengawal laluan rangkaian; ia tidak mengawal perisian yang sudah berjalan pada peranti. Saya menjalankan urutan ini pada setiap mesin yang kliennya mendakwa fail-closed, dan ia mengambil masa kira-kira sepuluh minit.

Mulakan dari klien, bukan dari pelayan

Titik penguatkuasaan ialah hos tempat anda duduk: tembok api sistem pengendalian, perkhidmatan pembantu atau pemacu klien VPN itu sendiri. Ini penting kerana semua yang boleh dilakukan oleh suis terhad kepada apa yang dilihat oleh lapisan itu. Jika klien melaksanakan sekatan dengan peraturan penghalaan dan tanda, apa sahaja dengan keistimewaan yang cukup boleh menambah peraturannya sendiri; jika ia menggunakan jadual tembok api kernel, keistimewaan yang sama boleh mengedit jadual itu. Kekuatan sifer tidak pernah masuk ke dalam soalan ini.

Jadi perkara pertama yang perlu ditetapkan ialah siapa yang memiliki dasar pada peranti ini dan apa yang dibenarkan untuk diatasinya. Pada mesin kerja terurus jawapannya biasanya ejen titik akhir organisasi, dan VPN peribadi tidak menghapuskan keupayaan itu, bagaimana pun terowong dikonfigurasikan.

Langkah satu: sahkan sekatan pada laluan yang anda percaya dilindungi

Turunkan terowong di hujung jauh, bukan pada klien, supaya klien masih percaya ia sepatutnya bersambung. Kemudian cuba apa yang benar-benar akan dicuba oleh seseorang:

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 mahu klien yang gagal dengan pantas dan bersih, bukan yang tergantung sehingga tamat masa pelayar. Tergantung biasanya bermaksud paket digugurkan secara senyap oleh peraturan tanpa penolakan, yang boleh diterima, tetapi ia juga boleh bermakna klien meninggalkan laluan lalai lama yang menuju antara muka mati. Baca jadual penghalaan semasa terowong turun: laluan lalai yang masih menunjuk ke peranti terowong dan peraturan tembok api yang hanya menyekat sambungan keluar baharu ialah dua keadaan berbeza, dan hanya satu daripadanya fail-closed.

Ulang perintah yang sama dengan pilihan allow-LAN klien dihidupkan dan dimatikan. Suis itulah tempat kebanyakan kejutan tinggal, kerana ia membuka semula laluan yang sepatutnya ditutup oleh seluruh dasar yang lain.

Langkah dua: periksa DNS dan IPv6 sebagai laluan berasingan

Penyelesaian nama ialah jurang yang bertahan dalam kebanyakan pelaksanaan, kerana pertanyaan boleh keluar melalui sesuatu selain penyelesai sistem. Tanyalah dengan alat yang mengabaikan konfigurasi penyelesai anda, dan periksa bahagian v6 sekali gus:

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

Jawapan kosong untuk kedua-dua pertanyaan nama semasa terowong turun ialah hasil yang anda mahukan. Jika pertanyaan kedua menjawab, alamat penyelesai yang dikodkan keras boleh dicapai dan terowong bukan satu-satunya jalan keluar dari mesin. Jika hanya permintaan v6 berjaya, dasar meliputi IPv4 dan mengabaikan IPv6, yang merupakan kebocoran yang sama dalam keluarga alamat lain.

Pelayar menjadikan ini lebih sukar dibaca dari luar, kerana pelayar yang dikonfigurasikan untuk DNS melalui HTTPS menyelesaikan pertanyaan melalui permintaan HTTPS: pertanyaan hanya disekat setakat port 443 ke titik akhir itu disekat. Pada hos yang dasarnya membenarkan subnet tempatan, permintaan itu masih boleh mencapai penyelesai di LAN.

Langkah tiga: pisahkan pendedahan rangkaian daripada pendedahan titik akhir

Kini bahagian yang tidak dicapai oleh mana-mana peraturan tembok api. Suis maut menyekat laluan keluar dari mesin; ia tidak menghalang perisian pada mesin daripada membaca data sebelum ia disulitkan, dan ia tidak menghalang perisian itu daripada menggunakan terowong secara sah. Perekod ketukan kekunci, sambungan berniat jahat, skrin yang dibiarkan tidak berkunci, klien penyegerakan dengan kebenaran luas: semuanya memindahkan maklumat melalui sambungan yang suis dengan senang hati benarkan.

Perkara yang sama berlaku untuk perisian pemantauan yang dipasang oleh majikan dengan sengaja. Menyekat laluan tidak menghapuskannya, dan membeli pelayan VPN baharu bukan pembaikannya, kerana pendedahan itu berada di hulu terowong.

Pengurus papan keratan yang memuat naik ke akaun awan menunjukkan perkara itu dengan tajam. Trafik disulitkan, destinasi dibenarkan, dan suis maut melaporkan keadaan sihat sepanjang masa.

Langkah empat: tulis dakwaan yang disokong oleh ujian anda

Selepas ujian gangguan anda boleh menyatakan fakta khusus: aplikasi mana yang gagal, laluan mana yang berhenti, bagaimana DNS dan IPv6 berkelakuan, dan sama ada sekatan bertahan apabila terowong jatuh. Anda tidak boleh menyatakan bahawa sistem pengendalian bersih, dan tidak boleh menyatakan bahawa perkhidmatan di hujung jauh akan merahsiakan log masuk anda.

Jauhkan kedua-dua masalah dan berikan setiap satu kawalannya sendiri:

• Suis maut: keperluan kegagalan yang ditetapkan, disahkan oleh ujian gangguan yang anda ulangi selepas setiap peningkatan klien.
• Kepercayaan peranti: kemas kini yang disokong, perlindungan titik akhir daripada sumber yang dipercayai, semakan kebenaran dan permintaan pengesahan yang tidak dijelaskan.
• Insiden: ikut proses platform atau organisasi apabila pencerobohan disyaki; pelayan baharu bukan langkah pembersihan.
• Pendedahan: apabila meminta bantuan, jangan tampal kunci peribadi atau arkib diagnostik penuh, kerana log dan tangkapan skrin membawa rahsia yang sama seperti sambungan.

Jalankan urutan lagi selepas kemas kini seterusnya, kerana suis maut ialah konfigurasi yang bergerak bersama versi. Ujian itu satu-satunya bukti bahawa tingkah laku yang anda harapkan masih tingkah laku yang anda peroleh.