Aturan UFW Baru, Koneksi Lama: Status Established Menang

Menambahkan aturan penolakan lalu melihat unduhan yang terbuka terus berjalan bukanlah bug UFW. Aturan yang Anda tambahkan berada setelah aturan yang sudah menerima aliran itu, dan koneksi yang terbentuk sebelumnya terus mencocokinya. Memperbaikinya berarti menyisipkan di posisi yang tepat dan memahami apa yang dijanjikan aturan sebelumnya. Versi sempit dari perubahan itu adalah berikut ini.

Urutan yang menentukan, bukan keberadaan aturan

UFW adalah antarmuka yang menulis aturan netfilter secara bertahap: bagian kerangka yang berjalan sebelum aturan pengguna, lalu aturan pengguna itu sendiri, lalu bagian yang berjalan setelahnya. Aturan sebelum bawaan menerima lalu lintas koneksi established dan related, dan aturan itu dievaluasi sebelum apa pun yang Anda tambahkan dengan allow atau deny biasa. Referensi perintah UFW mendokumentasikan sintaks penyisipan dan tampilan status bernomor yang menjadi dasar perubahan ini.

Urutan itulah yang menjelaskan keanehannya. Aturan baru Anda nyata dan berada di tabel yang benar, tetapi bukan keputusan pertama yang ditemui paket. Koneksi yang sudah dilacak sebagai established tidak pernah mencapainya.

Gunakan aturan route untuk tugas ini, karena paket diteruskan melalui gateway alih-alih dialamatkan ke layanan gateway itu sendiri. Aturan input akan menyaring lalu lintas yang salah dan tampak tidak melakukan apa pun.

Sisipkan di atas izin yang luas

Pratinjau penyisipan sebelum menerapkannya, dan pastikan aturan itu belum ada di tempat lain dalam daftar. Menduplikasi kebijakan yang identik membuat penghapusan nanti ambigu, dan orang yang menghapus salinan yang salah tidak akan menyadarinya selama berminggu-minggu.

sudo ufw --dry-run route insert 1 deny in on tun0 proto tcp from 10.88.0.55/32 to 192.0.2.88/32

Jika pratinjau menunjukkan tepat satu aturan di posisi yang Anda harapkan, terapkan perintah yang sama tanpa flag dry-run. Posisi 1 menempatkannya di atas izin pengguna yang lebih luas, bukan di atas aturan kerangka yang dibahas sebelumnya. Pastikan nama antarmuka cocok dengan perangkat tunnel di gateway ini, karena aturan yang dibatasi pada antarmuka yang sudah tidak ada akan tetap duduk di daftar dan tampak benar sambil tidak mencocoki apa pun. Ganti nama referensi perangkat sebelum menerapkan, bukan setelah pengujian gagal.

Tidak ada port tujuan dalam aturan itu, jadi ia menolak setiap port TCP pada alamat tersebut, bukan hanya HTTPS. Jika maksudnya satu layanan, sebutkan portnya; aturan yang lebih luas daripada kebijakan adalah insiden masa depan yang menunggu pembaca pertamanya.

Batasi sumber ke satu alamat hanya jika alamat itu terikat pada identitas yang dimaksud. Kumpulan VPN dengan penetapan dinamis dapat memberikan alamat yang sama kepada klien lain besok, dan penolakan akan mengikuti alamat itu, bukan orangnya.

Aliran established bertahan dari aturan baru

Pelacakan koneksi adalah alasan sesi yang ada berlanjut. Begitu suatu aliran tercatat sebagai established, aturan sebelum menerima paketnya sebelum penolakan Anda dilihat, dan transfer selesai seolah tidak ada yang berubah. Karena itu, menguji dengan peramban yang menggunakan ulang koneksi terbuka tidak memberi tahu apa pun tentang kebijakan baru. Penolakan bisa tampak tidak berguna beberapa menit setelah penerapan dan sepenuhnya efektif bagi pengguna berikutnya yang terhubung.

Jika persyaratan mencakup pemutusan lalu lintas aktif, perubahan aturan pengguna ini tidak dapat memberikannya. Mencabut status terlacak adalah tindakan terpisah dengan radius dampaknya sendiri, dan itu milik pemilik firewall, bukan orang yang menambahkan aturan. Mengosongkan setiap koneksi di gateway agar satu sesi hilang adalah jenis perbaikan yang memicu insiden kedua.

Ingat juga batasannya. Aturan ini tidak mengatakan apa pun tentang ICMP, UDP, atau IPv6, jadi ping yang berhasil bukan bukti bahwa penolakan gagal. Satu alamat IPv4 juga bukan situs web: sebuah nama dapat diresolusi ke beberapa alamat, dan hanya yang Anda sebutkan yang tercakup.

Uji dengan aliran baru

Baca aturan pengguna bernomor dan tampilan mentah yang efektif, lalu buka koneksi baru dari klien yang dipilih:

sudo ufw status numbered
sudo ufw show raw
# from 10.88.0.55, a new TCP connection to 192.0.2.88 should fail

Tampilan mentah penting karena status menghilangkan aturan kerangka yang ditulis dengan tangan, sehingga urutannya bisa tampak berbeda dari yang ditegakkan kernel. Bandingkan keduanya sebelum menyimpulkan bahwa suatu aturan berada di tempat yang salah.

Lalu periksa dua kontrol yang membuktikan aturan itu sempit dan bukan luas: tujuan yang diizinkan dari klien yang sama masih berfungsi, dan klien kedua masih mencapai tujuan yang ditolak jika kebijakannya mengizinkannya. Penolakan yang merusak kedua pengujian adalah perubahan kebijakan, bukan tindakan bertarget.

Setelah pengujian selesai, hapus hanya aturan yang Anda tambahkan, dengan menyebutkannya kembali secara persis. Jika kebijakan itu permanen, serahkan kepada pemilik firewall beserta identitas klien, pemilik tujuan, dan tanggal peninjauan, supaya alamat tunnel yang dialihkan tidak meninggalkan penolakan usang.