Tidak ada tun0? Cocokkan IPsec yang didekripsi di nftables dengan meta ipsec

Anda mengharapkan antarmuka terowongan, mencarinya, dan tidak ada yang bisa dicocokkan di firewall. Itu normal untuk gateway berbasis kebijakan: pertukaran terenkripsi tiba di antarmuka fisik, dan paket dalam yang telah didekripsi yang kemudian diteruskan juga teramati tiba di antarmuka yang sama. Tidak ada tun0 karena tidak ada yang membuatnya.

Permintaan dalam tetap merupakan paket tersendiri dengan sumber, tujuan, dan layanannya sendiri, dan kernel tahu dari asosiasi keamanan mana paket itu keluar. Pengetahuan itulah yang dapat dicocokkan oleh aturan firewall.

Dua paket, satu antarmuka

Bayangkan arah masuk. Paket yang dienkapsulasi ESP atau UDP tiba, kernel menemukan kebijakan yang cocok, mendekripsinya, dan menyerahkan paket bersih ke jalur penerusan. Aturan yang hanya melihat nama antarmuka tidak dapat membedakan paket itu dari lalu lintas lain yang tiba di kabel yang sama.

Yang membedakannya adalah konteks jalur keamanan masuk yang melekat pada paket. nftables menampilkannya sebagai meta ipsec exists, yang benar ketika paket tiba melalui jalur keamanan IPsec. Gabungkan dengan kumpulan klien, tujuan, dan layanan, dan aturannya menjadi cukup spesifik untuk aman.

Menghilangkan konteks adalah kesalahan umum, dan itu kesalahan keamanan, bukan kesalahan kosmetik. Aturan yang menerima apa pun yang berasal dari kumpulan klien sama senangnya menerima paket palsu dari jaringan lokal, karena alamat sumber bukan bukti apa pun dengan sendirinya. Konteks jalur keamanan adalah cara termurah untuk membuat sumber menjadi bermakna. Tulis aturannya dengan konteks itu sejak awal, bukan menambahkannya setelah audit.

Tulis aturan penerusan

Misalkan ada layanan akses jarak jauh IPv4 yang terautentikasi dengan klien di 10.90.0.0/24 dan satu tujuan yang disetujui di 203.0.113.40. Potongan aturan untuk aliran itu tampak seperti ini.

meta ipsec exists ip saddr 10.90.0.0/24 \
  ip daddr 203.0.113.40 tcp dport 443 \
  oifname "eth0" counter accept

Alamat dan antarmuka adalah contoh untuk diganti. Tempatkan padanan yang telah ditinjau di kebijakan penerusan sebelum aturan yang jika tidak akan menolak aliran itu, dan jangan mengosongkan kumpulan aturan yang ada untuk memasangnya; gateway bukanlah eksperimen ruang bersih.

Istilah oifname layak dipertahankan. Istilah itu mendokumentasikan keputusan keluar dan mencegah aturan cocok pada arah yang tidak Anda maksud, yang penting pada gateway dengan beberapa jalur ke internet. Pada kotak uji dengan satu uplink istilah itu tampak berlebihan, dan justru karena itulah istilah itu dihapus sebelum kotak tersebut mendapat uplink kedua.

Izin untuk pertukaran luar terpisah. Jalur masukan gateway memerlukan port IKE dan ESP atau enkapsulasi UDP yang benar-benar digunakannya, dan izin itu tidak mengizinkan apa pun mengenai paket yang didekripsi di dalam. Mencampur keduanya adalah cara sebuah terowongan yang berfungsi berakhir dengan firewall yang meneruskan semuanya.

Konteks masuk bukan konteks keluar

Keluarga ekspresi yang sama mencakup arah lain dengan rt ipsec, yang menjelaskan asosiasi keamanan keluar yang akan digunakan sebuah paket. Ekspresi itu menjawab pertanyaan berbeda: bukan dari mana paket ini datang, melainkan apakah paket itu akan dilindungi pada langkah berikutnya.

Perbedaan itu penting pada gateway yang sekaligus mengakhiri satu terowongan dan meneruskan ke terowongan lain. Sebuah paket dapat tiba dalam keadaan didekripsi dan tetap harus keluar dalam keadaan terenkripsi, dan penerimaan yang ditulis hanya untuk konteks masuk tidak mengatakan apa pun tentang persyaratan keluar. Jika kebijakan menuntut perlindungan itu, kumpulan aturan seharusnya menyatakannya alih-alih menganggap perutean akan menanganinya.

Simpan kedua pertanyaan dalam aturan terpisah agar pembaca dapat melihat mana yang ditegakkan. Satu aturan pintar yang memeriksa keduanya lebih sulit ditinjau dan jauh lebih sulit di-debug ketika separuhnya berhenti cocok. Dua aturan dengan penghitung juga memberi tahu Anda persyaratan mana yang gagal, sesuatu yang tidak akan pernah dilakukan satu aturan gabungan.

NAT bukan keputusan firewall

Lalu lintas menuju internet dari kumpulan klien privat biasanya memerlukan penerjemahan sumber agar balasannya menemukan jalan kembali. Tetapi lalu lintas yang dipilih untuk kebijakan IPsec keluar lain harus mempertahankan pengecualian yang diperlukan, dan menyamarkan setiap sumber privat tanpa memikirkan keputusan perlindungan berikutnya merusak hal itu.

Penerimaan di dalam rantai NAT juga bukan izin umum. NAT dan penyaringan memiliki tugas berbeda, dan rantai NAT tidak memeriksa setiap paket berikutnya dari aliran yang sudah terbentuk, dan justru itulah sebabnya mengandalkannya untuk keamanan menghasilkan aturan yang tampak berfungsi saat uji dan gagal di bawah beban.

Sebaliknya juga benar dan mengejutkan orang: penerimaan di suatu tempat dalam satu rantai dasar penyaringan tidak memiliki bobot apa pun terhadap penolakan berikutnya di rantai lain yang berlaku. Urutan dan cakupan rantai yang menentukan hasilnya, bukan keberadaan penerimaan dalam berkas.

Verifikasi layanan dalam yang tepat

Uji tujuan dan port spesifik yang Anda izinkan, dari klien sungguhan, dan pastikan balasannya kembali. Lalu uji sesuatu yang tidak Anda izinkan dan pastikan hal itu tidak lolos, karena aturan yang terlalu lebar lolos uji pertama sama baiknya dengan aturan yang benar. Permintaan yang tidak pernah meninggalkan klien juga bukan hasil firewall, jadi baca penghitungnya untuk melihat apakah paket itu dievaluasi sama sekali. Dua uji dan satu pembacaan penghitung akan memberi tahu Anda lebih banyak daripada sepanjang sore membaca kumpulan aturan.

Referensi nftables mendokumentasikan meta ipsec, rt ipsec, dan ekspresi khusus arah, dan di situlah tempat memeriksa sintaksis terhadap versi yang Anda pasang. Dan jaga cakupannya tetap jelas: ini contoh IPv4, tidak mengatakan apa pun tentang IPv6, dan tidak menjadikan penerusan port publik sembarangan sebagai bagian dari layanan VPN.