Bagikan melalui


Filter Arbitrase

Arbitrase filter adalah logika yang disertakan dalam Windows Filtering Platform (WFP) yang digunakan untuk menentukan bagaimana filter berinteraksi satu sama lain saat membuat keputusan pemfilteran lalu lintas jaringan.

Filter Perilaku Arbitrase

Perilaku berikut mencirikan sistem arbitrase filter:

  • Semua lalu lintas dapat diperiksa. Tidak ada lalu lintas yang dapat melewati filter pada lapisan tertentu.
  • Lalu lintas dapat diblokir oleh filter callout melalui Veto meskipun filter prioritas yang lebih tinggi telah mengizinkannya.
  • Beberapa penyedia dapat memeriksa lalu lintas pada lapisan yang sama. Misalnya, firewall diikuti oleh filter sistem deteksi intrusi (IDS), atau IPsec diikuti oleh filter Quality of Service (QoS) semuanya dapat memeriksa lalu lintas pada lapisan yang sama.

Model Pemfilteran

Setiap lapisan filter dibagi menjadi sub-lapisan yang diurutkan berdasarkan prioritas (juga disebut berat). Lalu lintas jaringan melintasi sub-lapisan dari prioritas tertinggi ke prioritas terendah. Sub-lapisan dibuat dan dikelola oleh pengembang menggunakan API WFP.

Dalam setiap sub-lapisan, filter diurutkan berdasarkan berat. Lalu lintas jaringan diindikasikan untuk mencocokkan filter dari bobot tertinggi ke bobot terendah.

Algoritma arbitrase filter diterapkan ke semua sub-lapisan dalam lapisan dan keputusan pemfilteran akhir dibuat setelah semua sub-lapisan dievaluasi. Ini menyediakan beberapa kemampuan pencocokan.

Dalam sub-lapisan, arbitrase filter dilakukan sebagai berikut:

  • Menghitung daftar filter pencocokan yang diurutkan berdasarkan berat dari tertinggi ke terendah.
  • Evaluasi filter yang cocok secara berurutan hingga "Izin" atau "Blokir" dikembalikan (filter juga dapat mengembalikan "Lanjutkan") atau sampai daftar habis.
  • Lewati filter yang tersisa dan kembalikan tindakan dari filter terakhir yang dievaluasi.

Dalam lapisan, arbitrase filter dilakukan sebagai berikut:

  • Lakukan arbitrase filter di setiap sub-lapisan secara berurutan dari prioritas tertinggi hingga prioritas terendah.
  • Evaluasi semua sub-lapisan bahkan jika sub-lapisan prioritas yang lebih tinggi telah memutuskan untuk memblokir lalu lintas.
  • Mengembalikan tindakan yang dihasilkan berdasarkan aturan kebijakan yang dijelaskan di bagian berikut.

Diagram di bawah ini mengilustrasikan contoh konfigurasi sub-lapisan. Kotak luar mewakili lapisan. Kotak dalam mewakili sub-lapisan yang berisi filter. Kartubebas (*) dalam filter berarti semua lalu lintas cocok dengan filter.

contoh konfigurasi sub-lapisan

Satu-satunya cara agar filter dilewati adalah jika filter bobot yang lebih tinggi telah mengizinkan atau memblokir lalu lintas dalam sub-lapisan yang sama. Sebaliknya, salah satu cara untuk memastikan bahwa filter selalu melihat semua lalu lintas dalam lapisan adalah dengan menambahkan sub-lapisan yang berisi satu filter yang cocok dengan semua lalu lintas.

Kebijakan Penggantian yang Dapat Dikonfigurasi

Aturan yang dijelaskan di bawah ini mengatur keputusan arbitrase dalam lapisan. Aturan ini digunakan oleh mesin filter untuk memutuskan tindakan sub-lapisan mana yang diterapkan ke lalu lintas jaringan.

Kebijakan dasarnya adalah sebagai berikut.

  • Tindakan dievaluasi dalam urutan prioritas sub-lapisan dari prioritas tertinggi ke prioritas terendah.
  • "Blokir" mengambil alih "Izin".
  • "Blokir" bersifat final (tidak dapat ditimpa) dan menghentikan evaluasi. Paket dibuang.

Kebijakan dasar tidak mendukung skenario pengecualian yang tidak ditimpa oleh firewall. Contoh umum dari jenis skenario ini adalah:

  • Port administrasi jarak jauh harus dibuka bahkan di hadapan firewall pihak ketiga.
  • Komponen yang mengharuskan port dibuka agar berfungsi (misalnya, UPnP Universal Plug and Play). Jika administrator telah secara eksplisit mengaktifkan komponen, firewall tidak boleh memblokir lalu lintas secara diam-diam.

Untuk mendukung skenario di atas, keputusan pemfilteran harus dibuat lebih sulit untuk diambil alih daripada keputusan pemfilteran lain dengan mengelola izin penimpaan tindakan. Izin ini diimplementasikan sebagai bendera FWPS_RIGHT_ACTION_WRITE dan diatur berdasarkan per filter.

Algoritma evaluasi mempertahankan tindakan saat ini ("Izin" atau "Blokir") bersama dengan bendera FWPS_RIGHT_ACTION_WRITE. Bendera mengontrol apakah sub-lapisan prioritas yang lebih rendah diizinkan untuk mengambil alih tindakan. Dengan mengatur atau mengatur ulang bendera FWPS_RIGHT_ACTION_WRITE dalam struktur FWPS_CLASSIFY_OUT0, penyedia mengatur bagaimana tindakan dapat atau tidak dapat ditimpa. Jika bendera diatur, itu menunjukkan bahwa tindakan dapat ditimpa. Jika bendera tidak ada, tindakan tidak dapat ditimpa.

Perbuatan Izinkan penimpaan (FWPS_RIGHT_ACTION_WRITE diatur) Deskripsi
Biar Ya Lalu lintas dapat diblokir di sub-lapisan lain. Ini disebut izin sementara.
Biar Tidak Lalu lintas dapat diblokir di sub-lapisan lain hanya dengan panggilan Veto. Ini disebut izin keras.
Halangi Ya Lalu lintas dapat diizinkan di sub-lapisan lain. Ini disebut blok lunak.
Halangi Tidak Lalu lintas tidak dapat diizinkan di sub-lapisan lain. Ini disebut blok keras.

Tindakan filter dapat diatur dengan mengatur jenis anggota dalam struktur FWPM_ACTION0 ke FWP_ACTION_BLOCK atau FWP_ACTION_PERMIT. Bersama dengan jenis tindakan, filter juga mengekspos bendera FWPM_FILTER_FLAG_CLEAR_ACTION_RIGHT. Jika bendera ini dibersihkan, maka jenis tindakan keras dan tidak dapat ditimpa kecuali ketika izin keras diambil alih oleh Veto seperti yang dijelaskan kemudian, jika tidak itu lunak yang dapat ditimpa oleh tindakan prioritas tinggi.

Tabel berikut mencantumkan perilaku default untuk tindakan filter dan callout.

Perbuatan Perilaku Default
Izin filter Izin sementara
Izin callout Izin sementara
Blok filter Blok keras
Blok callout Blok lunak

Veto adalah tindakan "Blokir" yang dikembalikan oleh filter saat bendera FWPS_RIGHT_ACTION_WRITE direset sebelum memanggil filter. Veto akan memblokir lalu lintas yang diizinkan dengan izin keras.

Ketika Veto dikeluarkan, itu adalah indikasi konflik dalam konfigurasi. Tindakan berikut diambil untuk mengurangi konflik.

  • Lalu lintas diblokir.

  • Peristiwa audit dihasilkan.

  • Pemberitahuan dibuat.

    Nota

    Pemberitahuan diterima oleh semua entitas yang telah berlangganannya. Ini biasanya akan mencakup firewall (untuk mendeteksi kesalahan konfigurasi), atau aplikasi (untuk mendeteksi apakah filter khusus mereka ditimpa).

    Nota

    Tidak ada antarmuka pengguna wajib (UI) yang dibuat saat filter "Izin Keras" ditimpa. Pemberitahuan penimpaan dikirim ke penyedia apa pun yang terdaftar untuk menerimanya, yang memungkinkan firewall, atau aplikasi yang membuat filter "Izin", untuk menunjukkan UI yang meminta tindakan pengguna. Tidak ada nilai dalam memiliki pemberitahuan UI platform untuk peristiwa penimpaan ini karena ISV firewall yang tidak ingin memblokir secara diam-diam dapat melakukannya dengan mendaftar di tempat yang berbeda di WFP, atau (kurang disukai) menangani semua logika mereka dalam driver panggilan keluar. ISV yang menurutnya meminta pengguna adalah ide yang baik akan ingin memiliki pengalaman pengguna dan membuat UI mereka sendiri.

Perilaku mitigasi yang dijelaskan di atas memastikan bahwa filter "Izin Keras" tidak ditimpa secara diam-diam oleh filter "Blokir", dan mencakup skenario di mana port administrasi jarak jauh tidak diizinkan untuk diblokir oleh firewall. Untuk secara diam-diam mengambil alih filter "Izin Keras" firewall harus menambahkan filternya dalam sub-lapisan prioritas yang lebih tinggi.

Nota

Karena tidak ada arbitrase lapisan silang, lalu lintas yang diizinkan dengan "Izin Keras" mungkin masih diblokir di lapisan lain. Penulis kebijakan bertanggung jawab untuk memastikan bahwa lalu lintas diizinkan di setiap lapisan jika perlu.

Aplikasi pengguna yang meminta port dibuka, tambahkan filter yang dapat diganti ke sub-lapisan prioritas rendah. Firewall dapat berlangganan filter menambahkan peristiwa pemberitahuan dan menambahkan filter yang cocok setelah validasi pengguna (atau kebijakan).

Penetapan Bobot Filter