IPDS | WAF

Daftar Isi

Tampilan Aturan WAF
Memahami Sistem Aturan OWASP CRS

Web Application Firewall (WAF) adalah alat penting untuk mengidentifikasi dan mencegah lalu lintas HTTP berbahaya di dalam farm HTTP(S). WAF menganalisis pola lalu lintas dan menerapkan kebijakan keamanan tingkat lanjut melalui serangkaian aturan terorganisir yang diterapkan pada farm tersebut. Setelah mendekripsi paket SSL, WAF meneliti aturan-aturan tersebut, sehingga memungkinkan WAF untuk menerapkan pola pada isi HTTP di dalam lalu lintas SSL.

The RELIANOID IPDS paket termasuk Kumpulan Aturan Inti ModSecurity OWASP, yang sudah dimuat sebelumnya dan siap digunakan. Pengguna juga memiliki fleksibilitas untuk membuat aturan khusus untuk perlindungan sistem yang komprehensif terhadap berbagai serangan. Untuk detail selengkapnya tentang aturan OWASP, lihat Proyek ModSecurity OWASP. Selain itu, RELIANOID Modul WAF memperluas fungsinya di luar perlindungan HTTP untuk disertakan penanganan konten HTTP tingkat lanjut fitur, seperti pengalihan dan penulisan ulang.

Tampilan Aturan WAF #

Tampilan kumpulan aturan WAF memberikan gambaran umum tentang kumpulan aturan yang tersedia dan layanan pertanian yang ditugaskan kepada mereka:

Nama. Pengidentifikasi deskriptif untuk kumpulan aturan. Klik untuk mengakses formulir pengeditan.
Pertanian. Peternakan yang menerapkan aturan tersebut. Perluas daftar pertanian menggunakan panah ke atas di sebelah PERTANIAN tajuk kolom. Terbatas hingga 20 karakter secara default.
Status. Status kumpulan aturan, ditunjukkan dengan kode warna:

Hijau. Enabled. Kumpulan aturan aktif dan sedang diperiksa untuk peternakan yang ditugaskan.
Merah. Disabled. Aturan tersebut tidak aktif dan tidak memengaruhi peternakan.

Tindakan . Tindakan yang tersedia untuk status aturan WAF:

Sunting. Ubah pengaturan aturan atau tetapkan layanan peternakan jika diperlukan.
Restart. Inisialisasi ulang aturan WAF.
Start. Terapkan aturan WAF.
Delete. Hapus seperangkat aturan.

Memahami Sistem Aturan OWASP CRS #

Aturan OWASP CRS terdiri dari aturan deteksi serangan generik, yang menawarkan tingkat perlindungan dasar untuk aplikasi web apa pun.

Mode operasi #

Rangkaian aturan OWASP CRS yang dimuat sebelumnya beroperasi dalam dua mode:

Mode Penilaian Anomali (default): Mode ini direkomendasikan karena informasi log yang akurat dan kebijakan pemblokiran yang fleksibel. Juga dikenal sebagai "mode deteksi kolaboratif," mode ini memberikan 'skor anomali' untuk setiap aturan yang cocok. Pada akhir evaluasi aturan masuk dan keluar, skor anomali memicu tindakan pemblokiran, yang biasanya menghasilkan kesalahan 403 secara default.

Mode Mandiri : Mode ini menerapkan tindakan secara instan. Meskipun mengurangi penggunaan sumber daya, mode ini mengorbankan fleksibilitas dalam kebijakan pemblokiran dan log audit terperinci (hanya ancaman pertama yang terdeteksi yang dicatat). Aturan mengikuti tindakan disruptif yang Anda tentukan (misalnya, tolak, jatuhkan). Aturan yang cocok pertama akan menjalankan tindakan ini, seringkali menyebabkan penghentian evaluasi setelah kecocokan awal, mirip dengan banyak IDS.

Aturan Dasar OWASP CRS #

Aturan perlindungan yang dimuat sebelumnya ini disusun berdasarkan preferensi. Jika Anda memilih untuk menggunakannya, mohon pertimbangkan dan terapkan dengan cara berikut:

PERMINTAAN-90-KONFIGURASI PERMINTAAN-901-INISIALISASI
# Terapkan aturan OWASP lainnya berdasarkan apa yang ingin Anda lindungi
PERMINTAAN-949-RESPONS-PEMBLOKIRAN-EVALUASI-959-RESPONS-EVALUASI PEMBLOKIRAN-980-KORELASI # untuk keperluan logging, aktifkan ini hanya untuk pemecahan masalah.

Dalam OWASP Core Rule Set, aturan REQUEST-901-INITIALIZATION berfungsi sebagai elemen dasar, menawarkan berbagai pilihan untuk mengkonfigurasi perilaku keseluruhan aturan keamanan. Aturan ini memberikan fleksibilitas kepada pengguna untuk menyesuaikan pengaturan agar sesuai dengan kebutuhan keamanan tertentu, membentuk tulang punggung proses konfigurasi aturan. Beralih ke aturan REQUEST-949-BLOCKING-EVALUATION dan RESPONSE-959-BLOCKING-EVALUATION , aturan-aturan ini memainkan peran penting dalam postur keamanan proaktif dengan mengevaluasi dan mengeksekusi tindakan pemblokiran berdasarkan skor anomali. Aturan-aturan ini berkontribusi secara signifikan terhadap kemampuan OWASP Core Rule Set untuk mengidentifikasi dan mencegah potensi ancaman secara real-time. Melengkapi hal tersebut, aturan RESPONSE-980-CORRELATION berfokus pada korelasi dan analisis respons, meningkatkan kemampuan keseluruhan OWASP Core Rule Set untuk mendeteksi dan merespons secara efektif terhadap tantangan keamanan yang terus berkembang. Secara bersama-sama, kumpulan aturan ini memberdayakan pengguna untuk menerapkan kerangka kerja keamanan yang kuat dan mudah beradaptasi untuk aplikasi web mereka.

Memahami Tingkat Paranoia, Sampling dan Skor Anomali #

Pengaturan Tingkat Paranoia memungkinkan Anda menentukan intensitas pemeriksaan aturan, yang memengaruhi skor anomali. Tingkat Paranoia yang lebih tinggi meningkatkan keamanan dengan mengaktifkan lebih banyak aturan namun dapat meningkatkan risiko pemblokiran lalu lintas yang sah karena kesalahan positif. Rekomendasi untuk setiap level:

Paranoia Tingkat 1 (default): Cocok untuk pemula, beragam instalasi, dan pengaturan keamanan standar, dengan kesalahan positif yang jarang terjadi.
Paranoia Tingkat 2: Direkomendasikan untuk pengguna tingkat menengah hingga berpengalaman yang mencari cakupan komprehensif dan keamanan yang lebih tinggi. Harapkan beberapa positif palsu.
Paranoia Tingkat 3: Ditujukan untuk pengguna berpengalaman yang menangani kesalahan positif, untuk instalasi dengan kebutuhan keamanan tinggi.
Paranoia Tingkat 4: Disarankan bagi pengguna berpengalaman yang melindungi instalasi dengan persyaratan keamanan yang sangat tinggi, namun kemungkinan besar menghasilkan positif palsu dalam jumlah besar yang memerlukan penyelesaian sebelum ditayangkan.

Untuk meningkatkan level paranoia pemblokiran , navigasikan ke Ruleset REQUEST-901-INITIALIZATION , lalu Edit dalam mode mentah dan ubah ID aturan 901120. Ganti setvar:'tx.blocking_paranoia_level=1′ dengan level yang Anda inginkan.

Dengan menggunakan tingkat paranoia deteksi , seseorang dapat menjalankan aturan dari tingkat paranoia yang lebih tinggi tanpa memperhitungkannya dalam penilaian anomali. Fleksibilitas ini memungkinkan penggabungan aturan dari tingkat paranoia 2 ke dalam sistem yang disetel dengan baik pada tingkat paranoia 1, mengurangi kekhawatiran tentang potensi positif palsu yang dapat meningkatkan skor melebihi ambang batas yang ditetapkan. Sebagai konfigurasi default, tingkat paranoia deteksi selaras dengan tingkat paranoia pemblokiran. Untuk meningkatkan tingkat paranoia deteksi , navigasikan ke Kumpulan Aturan REQUEST-901-INITIALIZATION , lalu Edit dalam mode mentah dan ubah ID aturan 901125. Ganti setvar:'tx.detection_paranoia_level=%{TX.blocking_paranoia_level}' dengan tingkat yang Anda inginkan (contoh: setvar:'tx.detection_paranoia_level=2′ ).

Setiap aturan dalam CRS diberi tingkat keparahan, dengan poin penilaian default yang menunjukkan dampak pada skor anomali ketika suatu aturan cocok. Tingkat keparahan dan skor yang sesuai adalah sebagai berikut:

KRITIS: Skor Anomali 5, terutama dari aturan serangan aplikasi (file 93x dan 94x).
ERROR: Skor Anomali 4, sebagian besar dihasilkan oleh aturan kebocoran keluar (95x file).
PERINGATAN: Skor Anomali 3, terutama dipicu oleh aturan klien jahat (file 91x).
PEMBERITAHUAN: Skor Anomali 2, terutama disebabkan oleh aturan protokol (file 92x).

Dalam mode anomali , skor-skor ini terakumulasi, memungkinkan satu permintaan untuk memicu beberapa aturan. Penyesuaian pada poin default ini umumnya tidak diperlukan tetapi dapat disesuaikan berdasarkan persyaratan spesifik.

Skor anomali kumulatif dapat didefinisikan sebagai skor di mana permintaan masuk atau respons keluar akan diblokir. Secara default, sebagian besar ancaman masuk yang terdeteksi menerima skor kritis 5, sementara pelanggaran yang lebih kecil memiliki skor yang lebih rendah. Pada ambang batas pemblokiran default, CRS berperilaku mirip dengan versi sebelumnya, memblokir dan mencatat permintaan dengan satu kecocokan aturan kritis. Menyesuaikan ambang batas pemblokiran ke nilai yang lebih tinggi, seperti 7 atau 10, dapat membuat CRS kurang sensitif, membutuhkan beberapa kecocokan aturan sebelum pemblokiran. Namun, perlu berhati-hati, karena menaikkan ambang batas dapat memungkinkan beberapa serangan untuk melewati aturan atau kebijakan. Sebagai alternatif, strategi penerapan yang direkomendasikan melibatkan pengaturan awal ambang batas skor anomali yang tinggi (>100) dan secara bertahap menurunkannya seiring dengan meningkatnya kepercayaan pada sistem, menawarkan pendekatan proaktif untuk meningkatkan keamanan dari waktu ke waktu.

Secara default, ambang batas skor anomali masuk diatur ke 5 dan ambang batas skor anomali keluar diatur ke 4. Untuk memodifikasi ambang batas skor anomali masuk , navigasikan ke Aturan REQUEST-901-INITIALIZATION , lalu Edit dalam mode mentah dan modifikasi ID aturan 901100. Ganti setvar:'tx.inbound_anomaly_score_threshold=5′ dengan level yang Anda inginkan (misalnya, setvar:'tx.inbound_anomaly_score_threshold=4′ ). Lakukan hal yang sama untuk ambang batas skor anomali keluar dengan ID aturan 901110 , ganti setvar:'tx.outbound_anomaly_score_threshold=4′.

Mode Pemblokiran Penilaian Anomali Awal memungkinkan penilaian awal skor anomali permintaan dan respons pada akhir fase 1 dan fase 3, masing-masing, alih-alih menunggu hingga akhir fase 2 dan fase 4. Mengaktifkan mode ini memungkinkan pemblokiran langsung jika ambang anomali tercapai selama evaluasi awal, melewati eksekusi fase 2 (dan fase 4, masing-masing). Untuk mengaktifkan pemblokiran awal, aktifkan aturan ID 901115 dalam kumpulan aturan REQUEST-901-INITIALIZATION , yang mengatur variabel tx.early_blocking menjadi 1 (dinonaktifkan secara default). Penting untuk dicatat bahwa pemblokiran awal dapat menyembunyikan potensi peringatan, karena muatan yang memicu peringatan fase 2 (atau fase 4) tidak akan dievaluasi jika pemblokiran awal diaktifkan. Menonaktifkan pemblokiran awal di masa mendatang dapat mengungkapkan peringatan baru dari fase 2.

Fitur Easing In / Sampling Percentage dirancang untuk mengurangi potensi masalah saat mengintegrasikan CRS ke situs web yang sudah ada, seperti false positive dan dampak kinerja yang tidak terduga. Untuk memperkenalkan CRS secara hati-hati, Anda dapat mengaktifkannya terlebih dahulu untuk sejumlah permintaan terbatas. Setelah semua masalah teratasi, dan kepercayaan pada pengaturan telah terbentuk, Anda dapat secara bertahap meningkatkan rasio permintaan yang dikenakan aturan tersebut. Sesuaikan persentase permintaan yang diproses oleh Aturan Inti dengan mengatur tx.sampling_percentage pada ID aturan 901130 dalam aturan REQUEST-901-INITIALIZATION ; nilai defaultnya adalah 100, yang berarti setiap permintaan menjalani pemeriksaan CRS. Pemilihan permintaan yang diperiksa didasarkan pada angka pseudo-acak yang dihasilkan oleh ModSecurity. Jika suatu permintaan diizinkan untuk lolos tanpa pemeriksaan CRS, permintaan tersebut tidak akan memiliki entri dalam log audit karena alasan kinerja, tetapi entri log kesalahan akan dicatat. Untuk menonaktifkan entri log kesalahan, berikan arahan yang ditentukan setelah menyertakan CRS.