Perubahan aturan firewall tidak berfungsi: urutan aturan dan status koneksi

Anda mengedit aturan, memuat ulang kumpulan aturan, dan terowongan berperilaku persis seperti sebelumnya. Hasil itu punya dua penyebab umum, dan keduanya memerlukan pengujian berbeda. Entah aturan baru berada setelah aturan sebelumnya yang sudah menerima paket, atau pertukaran yang Anda amati adalah koneksi terlacak yang tidak pernah dievaluasi ulang oleh perubahan itu. Aturan dalam berkas menyatakan niat; yang menentukan paket adalah jalur aktif yang ditemuinya. Jalankan pemeriksaan di bawah ini secara berurutan, dan pertahankan jalur kembali selama melakukannya.

Urutan aturan dan status koneksi adalah kesalahan yang berbeda

Rantai berurut dievaluasi dari atas ke bawah, dan aturan pertama yang mencapai putusan akhir mengakhiri penelusuran rantai itu. Letakkan penerimaan luas di atas aturan penguncian yang ditulis dengan cermat, dan aturan penguncian itu menjadi dokumentasi: ia ada di kumpulan aturan, penghitungnya nol, dan tidak ada paket yang akan pernah mencapainya. Teks yang sama diterapkan pada rantai lain juga tidak membuktikan apa pun. Di nftables, rantai dasar terpasang ke hook pada prioritas tertentu, sehingga penerimaan di satu rantai tidak mencegah rantai lain pada hook atau prioritas berbeda melihat paket yang sama.

Pelacakan koneksi menghasilkan gejala kedua, dan dari luar tampak identik. Begitu suatu aliran ada di tabel status, penerimaan untuk established-or-related di dekat puncak rantai kembali sebelum aturan baru Anda bahkan ditanyakan. Pemetaan NAT memiliki sifat yang sama: terjemahan ditetapkan saat aliran dimulai, sehingga aturan postrouting yang diedit tidak menulis ulang sesi yang sudah berjalan. Inilah sebabnya suatu perubahan tampak berhasil pada 09:00 untuk koneksi baru dan tampak tidak melakukan apa pun untuk sesi yang dibuka seseorang pada 08:55.

Grup keamanan cloud menambahkan model ketiga yang menangkap orang yang belajar dengan iptables. Aturan masuknya adalah daftar izin yang dievaluasi sebagai himpunan, bukan penelusuran kecocokan pertama, bersifat stateful, dan menghapus aturan izin tidak menghentikan aliran yang sudah dilacak. Mengasumsikan semantik kecocokan pertama pada platform yang tidak memilikinya menghasilkan kesimpulan yang yakin tetapi salah.

Baca kumpulan aturan aktif, bukan berkas yang Anda edit

Mulailah dari apa yang sedang ditegakkan kernel sekarang. Konfigurasi tersimpan yang tidak pernah diterapkan menjelaskan banyak perilaku yang tidak berubah, dan menyingkirkannya hanya perlu satu perintah:

nft list ruleset
iptables-save

Lalu tanyakan apakah aturan Anda tercapai sama sekali. Penghitung paket menjawabnya langsung, dan menjawabnya lebih baik daripada penalaran apa pun tentang niat:

iptables -L FORWARD -v -n --line-numbers
nft list chain inet filter forward

Aturan penguncian dengan nol paket setelah percobaan uji nyata bukan masalah kebijakan, melainkan masalah posisi. Memindahkannya adalah perubahan satu baris, dan sintaksnya justru hal yang menyebabkan bug awal. Dengan iptables, -I menyisipkan dan -A menambahkan di akhir; dengan nftables, insert menempatkan aturan di awal rantai sementara add menambahkan di akhir. Ketika suatu aturan harus menang, katakanlah secara eksplisit alih-alih memercayai urutan yang kebetulan dimuat.

Buktikan apakah aliran dilacak

Sebelum menyalahkan aturan, periksa apakah lalu lintas itu memang koneksi terlacak. Tanyakan tabel status untuk aliran tertentu alih-alih membuang seluruhnya:

conntrack -L -p tcp --dport 1194
conntrack -E -p tcp --dport 1194

Daftar menunjukkan status dan sisa waktu tunggu, dan begitulah cara Anda membedakan sesi yang sudah mapan dari percobaan baru; mode peristiwa mencetak pembaruan saat terjadi, yang berguna saat Anda menyambungkan ulang klien. Jika aliran sudah ada dengan status mapan sebelum Anda menyentuh apa pun, tidak ada penyuntingan aturan filter yang akan mengubah nasibnya. Itu bukan bug pada firewall, itu kontrak penyaringan stateful.

Tolak jalan pintas mengosongkan seluruh tabel pada gateway produksi. conntrack -F tersedia, dan itu juga menghancurkan setiap aliran terlacak di mesin, termasuk sesi manajemen tempat Anda bekerja dan terowongan yang membawa shell Anda. Entri individual bisa dihapus saat benar-benar perlu, tetapi aliran baru dari port sumber baru biasanya eksperimen yang lebih bersih.

Beberapa jalur tidak dilacak, dan berperilaku sebaliknya. Lalu lintas yang ditandai notrack di tabel raw, beberapa terowongan yang melewati hook normal, dan routing asimetris yang memecah aliran di antara dua gateway semuanya menghasilkan paket yang dievaluasi satu per satu, atau status yang tidak pernah dibuat di kedua ujung. Jika penghitung bergerak untuk setiap paket, curigai jalur semacam itu sebelum mencurigai urutannya.

Uji dari aliran baru dengan jalur kembali

Sebelum menguji aturan yang dapat memutus akses jarak jauh, bentuklah jalur pemulihan: konsol penyedia, konsol serial, alamat manajemen di luar pita, atau antarmuka kedua yang tidak dapat dicocokkan oleh aturan. Pengatur waktu rollback adalah pendamping yang wajar, karena ia akan memulihkan kumpulan aturan sebelumnya meskipun sesi Anda mati di tengah pengujian.

Lalu uji dengan pertukaran yang belum mungkin dicakup status. Putuskan dan sambungkan ulang klien agar lima-tupel baru dibuat, dan amati kedua ujung saat itu terjadi:

tcpdump -ni eth0 'tcp port 1194'
journalctl -k -n 50 --no-pager

Jalankan pengujian di kedua arah. Aturan yang memblokir jabat tangan masuk yang baru masih dapat mengizinkan jalur balasan, atau sebaliknya, dan hasil satu arah adalah alasan biasa sebuah penguncian hanya bekerja separuh. Sambungkan ulang sekali setelah pengujian untuk memastikan status tunak, dan periksa apakah akses manajemen yang sah bertahan; aturan yang ditulis untuk satu port punya kebiasaan cocok dengan rentang yang lebih luas daripada yang dimaksud.

Catat tujuan dan posisi bersama aturannya

Aturan tanpa tujuan tercatat adalah aturan yang tidak berani dihapus siapa pun. Di samping setiap entri penguncian, simpan aliran yang dilindunginya, rantai dan hook tempat ia hidup, posisi yang harus dijaganya terhadap penerimaan yang lebih luas, dan pengujian yang membuktikannya. Ketika seseorang mengedit kumpulan aturan di sekitarnya enam bulan kemudian, catatan itulah satu-satunya peringatan bahwa posisinya disengaja.

Sebelum menutup perubahan, pastikan empat hal: kumpulan aturan yang berjalan cocok dengan berkas, aturan baru memiliki penghitung bukan nol setelah percobaan baru, arah balik dan akses manajemen masih berfungsi, dan Anda sudah menyambung ulang sekali untuk membuktikan status tunak alih-alih status sesi yang lebih tua daripada perubahan. Jika ada yang belum terverifikasi, perubahan belum selesai, apa pun yang dilakukan terowongan.