IPDS | WAF

Lihat Kategori

IPDS | WAF

Baca min 6

. Firewall Aplikasi Web (WAF) ialah alat penting untuk mengenal pasti dan mencegah trafik HTTP berniat jahat dalam ladang HTTP(S). Ia menganalisis corak trafik dan menguatkuasakan dasar keselamatan lanjutan melalui set peraturan teratur yang digunakan untuk ladang ini. Selepas menyahsulit paket SSL, WAF meneliti peraturan, membenarkannya menggunakan corak pada badan HTTP dalam trafik SSL.

. RELIANOID IPDS pakej termasuk Set Peraturan Teras ModSecurity OWASP, yang datang pramuat dan sedia untuk digunakan. Pengguna juga mempunyai fleksibiliti untuk mencipta set peraturan tersuai untuk perlindungan sistem yang komprehensif terhadap pelbagai serangan. Untuk butiran lanjut tentang peraturan OWASP, rujuk Projek ModSecurity OWASP. Selain itu, RELIANOID Modul WAF memanjangkan fungsinya melangkaui perlindungan HTTP untuk disertakan pengendalian kandungan HTTP lanjutan ciri, seperti ubah hala dan penulisan semula.

Paparan Peraturan WAF #

Paparan set peraturan WAF memberikan gambaran keseluruhan set peraturan yang tersedia dan perkhidmatan ladang yang diperuntukkan kepada mereka:

relianoid load balancer v8 ipds waf farm ruleset

Nama. Pengecam deskriptif untuk set peraturan. Klik untuk mengakses borang pengeditan.
Farms. Ladang yang digunakan peraturan. Kembangkan senarai ladang menggunakan anak panah ke atas di sebelah FARMS pengepala lajur. Terhad kepada 20 aksara secara lalai.
status. Status set peraturan, ditunjukkan oleh kod warna:

  • Green. didayakan. Set peraturan aktif dan sedang diperiksa untuk ladang yang ditetapkan.
  • Merah. Kurang Upaya. Set peraturan tidak aktif dan tidak menjejaskan ladang.

Tindakan. Tindakan yang tersedia untuk status set peraturan WAF:

  • Edit. Ubah suai tetapan set peraturan atau tetapkan perkhidmatan ladang jika perlu.
  • restart. Memulakan semula peraturan WAF.
  • Start. Gunakan set peraturan WAF.
  • Padam. Keluarkan peraturan.

Memahami Sistem Peraturan OWASP CRS #

. OWASP CRS set peraturan terdiri daripada peraturan pengesanan serangan generik, menawarkan tahap perlindungan asas untuk sebarang aplikasi web.

Kaedah operasi #

Set peraturan pra-muat OWASP CRS beroperasi dalam dua mod:

Mod Pemarkahan Anomali (lalai): Mod ini disyorkan untuk maklumat log yang tepat dan dasar penyekatan yang fleksibel. Juga dikenali sebagai "mod pengesanan kolaboratif," ia memberikan 'skor anomali' kepada setiap peraturan padanan. Pada penghujung penilaian peraturan masuk dan keluar, skor anomali mencetuskan tindakan menyekat, biasanya mengakibatkan ralat lalai 403.

Mod Berdikari: Mod ini menggunakan tindakan serta-merta. Semasa mengurangkan penggunaan sumber, ia mengorbankan fleksibiliti dalam menyekat dasar dan log audit terperinci (hanya ancaman pertama yang dikesan direkodkan). Peraturan mengikut tindakan mengganggu yang anda tentukan (cth, nafi, lepas). Peraturan padanan pertama melaksanakan tindakan ini, selalunya membawa kepada pemberhentian penilaian selepas perlawanan awal, serupa dengan banyak IDS.

Peraturan Asas CRS OWASP #

Peraturan perlindungan pra-muat ini disusun berdasarkan keutamaan. Jika anda memilih untuk menggunakannya, sila pertimbangkan dan gunakannya dengan cara berikut:

PERMINTAAN-90-PERMINTAAN KONFIGURASI-901-PERMULAAN
# Gunakan mana-mana set peraturan OWASP lain berdasarkan perkara yang anda ingin lindungi
PERMINTAAN-949-RESPONS-PENILAIAN-SEKATAN-959-RESPONS-PENILAIAN-SEKATAN-980-KORELASI # untuk tujuan pengelogan, dayakan ini hanya untuk penyelesaian masalah.

Dalam Set Peraturan Teras OWASP, PERMINTAAN-901-INITIALISASI ruleset berfungsi sebagai elemen asas, menawarkan pelbagai pilihan untuk mengkonfigurasi gelagat keseluruhan peraturan keselamatan. Ia menyediakan pengguna dengan fleksibiliti untuk memperhalusi tetapan untuk menyelaraskan dengan keperluan keselamatan tertentu, membentuk tulang belakang proses konfigurasi peraturan. Berpindah ke REQUEST-949-BLOCKING-EVALUATION dan RESPONS-959-BLOCKING-EVALUATION peraturan, ini memainkan peranan penting dalam postur keselamatan proaktif dengan menilai dan melaksanakan tindakan menyekat berdasarkan skor anomali. Mereka menyumbang dengan ketara kepada keupayaan Set Peraturan Teras OWASP untuk mengenal pasti dan mencegah potensi ancaman dalam masa nyata. Melengkapkan ini, RESPONS-980-KORELASI ruleset menumpukan pada mengaitkan dan menganalisis respons, meningkatkan keupayaan keseluruhan Set Peraturan Teras OWASP untuk mengesan dan bertindak balas secara berkesan kepada cabaran keselamatan yang berkembang. Bersama-sama, set peraturan ini memperkasakan pengguna untuk melaksanakan rangka kerja keselamatan yang teguh dan boleh disesuaikan untuk aplikasi web mereka.

Memahami Tahap Paranoia, Pensampelan dan Skor Anomali #

Tetapan Tahap Paranoia membolehkan anda menentukan keamatan semakan peraturan, mempengaruhi skor anomali. Tahap Paranoia yang lebih tinggi meningkatkan keselamatan dengan mendayakan lebih banyak peraturan tetapi boleh meningkatkan risiko menyekat trafik yang sah disebabkan oleh positif palsu. Cadangan untuk setiap peringkat:

Paranoia Tahap 1 (lalai): Sesuai untuk pemula, pemasangan pelbagai dan tetapan keselamatan standard, dengan positif palsu yang jarang berlaku.
Paranoia Tahap 2: Disyorkan untuk pengguna sederhana hingga berpengalaman yang mencari liputan komprehensif dan keselamatan yang dipertingkatkan. Jangkakan beberapa positif palsu.
Paranoia Tahap 3: Ditujukan kepada pengguna berpengalaman yang mengendalikan positif palsu, untuk pemasangan dengan keperluan keselamatan yang tinggi.
Paranoia Tahap 4: Dinasihatkan untuk pengguna berpengalaman yang melindungi pemasangan dengan keperluan keselamatan yang sangat tinggi, tetapi berkemungkinan menghasilkan bilangan positif palsu yang tinggi yang memerlukan penyelesaian sebelum disiarkan secara langsung.

Untuk menaikkan menyekat tahap paranoia, navigasi ke PERMINTAAN-901-INITIALISASI Set peraturan, kemudian Edit dalam mod mentah dan ubah suai ID peraturan 901120. Ganti setvar:'tx.blocking_paranoia_level=1′ dengan tahap pilihan anda.

Dengan menggaji tahap paranoia pengesanan, seseorang boleh menjalankan peraturan dari tahap paranoia yang lebih tinggi tanpa memfaktorkannya ke dalam pemarkahan anomali. Fleksibiliti ini membolehkan penyepaduan peraturan daripada tahap paranoia 2 ke dalam sistem yang ditala halus pada tahap paranoia 1, mengurangkan kebimbangan tentang potensi positif palsu yang mungkin meningkatkan skor melebihi ambang yang ditetapkan. Sebagai konfigurasi lalai, tahap paranoia pengesanan sejajar dengan tahap paranoia menyekat. Untuk meningkatkan tahap paranoia pengesanan, navigasi ke PERMINTAAN-901-INITIALISASI Set peraturan, kemudian Edit dalam mod mentah dan ubah suai ID peraturan 901125. Ganti setvar:'tx.detection_paranoia_level=%{TX.blocking_paranoia_level}' dengan tahap pilihan anda (cth. setvar:'tx.detection_paranoia_level=2′).

Setiap peraturan dalam CRS diberikan tahap keterukan, dengan lalai pemarkahan mata menunjukkan kesan ke atas skor anomali apabila peraturan sepadan. Tahap keterukan dan skor yang sepadan adalah seperti berikut:

KRITIKAL: Skor Anomali 5, terutamanya daripada peraturan serangan aplikasi (fail 93x dan 94x).
RALAT: Skor Anomali 4, kebanyakannya dijana oleh peraturan kebocoran keluar (fail 95x).
BERKHATAN :: Skor Anomali 3, terutamanya dicetuskan oleh peraturan pelanggan berniat jahat (91x fail).
NOTIS: Skor Anomali 2, terutamanya terhasil daripada peraturan protokol (fail 92x).

In mod anomali, markah ini terkumpul, membenarkan satu permintaan untuk mencetuskan berbilang peraturan. Pelarasan pada titik lalai ini secara amnya tidak diperlukan tetapi boleh disesuaikan berdasarkan keperluan khusus.

Ia boleh ditakrifkan sebagai skor anomali kumulatif di mana an permintaan masuk or tindak balas keluar akan disekat. Secara lalai, kebanyakan ancaman masuk yang dikesan menerima skor kritikal 5, manakala pelanggaran yang lebih kecil membawa markah yang lebih rendah. Pada ambang penyekatan lalai, CRS berkelakuan serupa dengan versi sebelumnya, menyekat dan mengelog permintaan dengan satu padanan peraturan kritikal. Melaraskan ambang penyekatan kepada nilai yang lebih tinggi, seperti 7 atau 10, boleh menjadikan CRS kurang sensitif, memerlukan beberapa padanan peraturan sebelum menyekat. Walau bagaimanapun, berhati-hati dinasihatkan, kerana menaikkan ambang mungkin membenarkan beberapa serangan memintas peraturan atau dasar. Sebagai alternatif, strategi penggunaan yang disyorkan melibatkan pada mulanya menetapkan ambang pemarkahan anomali yang tinggi (>100) dan menurunkannya secara beransur-ansur apabila keyakinan terhadap sistem berkembang, menawarkan pendekatan proaktif untuk meningkatkan keselamatan dari semasa ke semasa.

Secara lalai, ambang skor anomali masuk ditetapkan kepada 5 dan ambang skor anomali keluar ditetapkan kepada 4. Untuk mengubah suai ambang skor anomali masuk, navigasi ke PERMINTAAN-901-INITIALISASI Set peraturan, kemudian Edit dalam mod mentah dan ubah suai ID peraturan 901100. Ganti setvar:'tx.inbound_anomaly_score_threshold=5′ dengan tahap pilihan anda (cth. setvar:'tx.inbound_anomaly_score_threshold=4′). Cara yang sama untuk ambang skor anomali keluar dengan ID peraturan 901110 menggantikan setvar:'tx.outbound_anomaly_score_threshold=4′.

. Penyekatan Mod Pemarkahan Anomali Awal membolehkan penilaian awal skor anomali permintaan dan tindak balas pada akhir fasa:1 dan fasa:3, masing-masing, bukannya menunggu sehingga akhir fasa:2 dan fasa:4. Mendayakan mod ini membenarkan penyekatan segera jika ambang anomali dicapai semasa penilaian awal, memintas pelaksanaan fasa 2 (dan fasa 4, masing-masing). Untuk mengaktifkan penyekatan awal, dayakan ID peraturan 901115 dalam PERMINTAAN-901-INITIALISASI ruleset, yang menetapkan pembolehubah tx.early_blocking kepada 1 (dilumpuhkan secara lalai). Adalah penting untuk ambil perhatian bahawa penyekatan awal mungkin menyembunyikan amaran yang berpotensi, kerana muatan yang mencetuskan makluman fasa 2 (atau fasa 4) tidak akan dinilai jika penyekatan awal dilakukan. Melumpuhkan sekatan awal pada masa hadapan mungkin mendedahkan makluman baharu dari fasa 2.

. Peratusan Pelonggaran / Persampelan ciri direka untuk mengurangkan isu yang berpotensi apabila menyepadukan CRS ke dalam tapak langsung sedia ada, seperti positif palsu dan kesan prestasi yang tidak dijangka. Untuk memperkenalkan CRS dengan berhati-hati, anda pada mulanya boleh mendayakannya untuk bilangan permintaan yang terhad. Setelah sebarang isu ditangani dan keyakinan terhadap persediaan diwujudkan, anda boleh meningkatkan nisbah permintaan yang tertakluk kepada set peraturan secara beransur-ansur. Laraskan peratusan permintaan yang diproses oleh Peraturan Teras dengan menetapkan tx.persampelan_peratusan pada ID peraturan 901130 dalam PERMINTAAN-901-INITIALISASI set peraturan; lalai ialah 100, bermakna setiap permintaan menjalani semakan CRS. Pemilihan permintaan yang disemak adalah berdasarkan nombor pseudo-rawak yang dijana oleh ModSecurity. Jika permintaan dibenarkan lulus tanpa semakan CRS, ia tidak akan mempunyai entri dalam log audit atas sebab prestasi, tetapi entri log ralat direkodkan. Untuk melumpuhkan kemasukan log ralat, keluarkan arahan yang ditentukan selepas memasukkan CRS.

📄 Muat turun dokumen ini dalam format PDF #

    E-MEL: *

    Dikuasai oleh BetterDocs