---
title: "ModSecurity + OWASP CRS: WAF Open-Source di Server Sendiri"
description: "Cara menjalankan ModSecurity atau Coraza dengan OWASP Core Rule Set, memilih paranoia level, mulai dari mode DetectionOnly, dan menyetel salah blokir."
url: "https://nivelva.com/insight/modsecurity-owasp-crs"
category: "Keamanan/Cyber Security"
tags: ["modsecurity","owasp crs","coraza","waf","nginx"]
author: "Theresia Candiawan"
published: "2026-11-07T02:17:00+07:00"
updated: "2026-11-07T02:17:00+07:00"
language: "id"
publisher: "Nivelva (https://nivelva.com)"
---

# ModSecurity + OWASP CRS: WAF Open-Source di Server Sendiri

> **Jawaban singkat:** ModSecurity atau Coraza adalah mesin WAF, sedangkan OWASP Core Rule Set (CRS) adalah kumpulan aturannya. Pasang mesinnya di web server, muat CRS, jalankan dulu dalam mode DetectionOnly di paranoia level 1, setel pengecualian untuk salah blokir, baru aktifkan blokir dengan ambang anomali 5.

Ingin punya WAF tanpa bergantung pada layanan pihak ketiga, dan sanggup merawatnya sendiri? Salah satu jalannya adalah mesin WAF open-source (ModSecurity atau Coraza) yang dipadukan dengan OWASP Core Rule Set. Semuanya gratis dan berjalan sepenuhnya di servermu.

Yang sering membuat orang menyerah bukan pemasangannya, tapi salah blokir di minggu pertama. Formulir tidak bisa dikirim, editor CMS menolak menyimpan, dan tim panik mematikan semuanya. Urutan langkah di bawah dirancang supaya hal itu tidak terjadi.

Kalau konsep WAF masih baru bagimu, mulai dari [apa itu WAF](https://nivelva.com/insight/apa-itu-waf).

## Langkah 1: pilih mesin WAF yang sesuai web server

Mesin WAF adalah komponen yang membaca request dan menjalankan aturan. Ada tiga pilihan utama.

**ModSecurity v2** adalah modul Apache. **ModSecurity v3** (libmodsecurity) adalah pustaka terpisah yang dihubungkan ke Nginx lewat konektor ModSecurity-nginx. Proyek ini kini dikelola di bawah organisasi OWASP di GitHub. Per 4 November 2026, rilis terbaru di halaman GitHub resminya adalah v3.0.17 untuk cabang v3 dan v2.9.15 untuk cabang v2.

**Coraza** adalah WAF open-source yang ditulis dengan Go dan berstatus OWASP Production Project. Menurut repositorinya, Coraza 100% kompatibel dengan CRS v4 dan bisa menjadi pengganti ModSecurity dengan kompatibilitas sebagian. Per 4 November 2026, README-nya mencantumkan integrasi untuk Caddy dan Proxy WASM (misalnya Envoy) dengan status stabil, sedangkan integrasi Traefik dan HAProxy SPOE masih berlabel eksperimental.

Pedoman singkatnya: Apache memakai ModSecurity v2, Nginx umumnya memakai ModSecurity v3, dan Caddy atau Envoy lebih cocok dengan Coraza. Untuk Traefik dan HAProxy, perhitungkan status eksperimental integrasinya sebelum dipakai di produksi. Pertimbangan memilih web server dibahas di [Nginx vs Apache vs LiteSpeed](https://nivelva.com/insight/nginx-apache-litespeed).

## Langkah 2: pasang mesin dalam mode DetectionOnly

Setelah modul terpasang dan dimuat, buka file konfigurasi utamanya (biasanya `modsecurity.conf`, dibuat dari contoh `modsecurity.conf-recommended`). Pastikan baris ini:

```apache
SecRuleEngine DetectionOnly
```

Dalam mode DetectionOnly, aturan tetap dievaluasi dan pelanggarannya dicatat ke audit log, tapi tidak ada request yang diblokir. Ini fondasi seluruh proses: kamu melihat apa yang akan diblokir tanpa mengganggu pengguna.

Di Nginx dengan konektor v3, aktifkan di blok server:

```nginx
modsecurity on;
modsecurity_rules_file /etc/nginx/modsec/main.conf;
```

File `main.conf` itulah yang memuat konfigurasi ModSecurity dan CRS.

## Langkah 3: muat OWASP Core Rule Set

CRS adalah kumpulan aturan generik untuk serangan umum seperti SQL injection, XSS, dan eksekusi perintah. Per 4 November 2026, halaman rilis GitHub CRS mencatat v4.30.0 sebagai rilis terbaru, dan v4.25.2 sebagai rilis LTS. Untuk server produksi yang jarang disentuh, jalur LTS bisa lebih nyaman.

Unduh rilis dari GitHub, salin `crs-setup.conf.example` menjadi `crs-setup.conf`, lalu muat berurutan di `main.conf`:

```apache
Include /etc/nginx/modsec/modsecurity.conf
Include /etc/nginx/modsec/crs/crs-setup.conf
Include /etc/nginx/modsec/crs/rules/*.conf
```

Jalankan `nginx -t`, reload, lalu kirim request uji yang jelas berbahaya, misalnya parameter berisi `<script>`. Request itu harus tetap berhasil (karena DetectionOnly), tapi tercatat di audit log.

## Langkah 4: pahami anomaly scoring dan paranoia level

CRS tidak memblokir pada aturan pertama yang cocok. Setiap aturan yang cocok menambah skor anomali sesuai tingkat keparahannya. Menurut dokumentasi CRS, nilai bawaannya CRITICAL 5, ERROR 4, WARNING 3, dan NOTICE 2. Request ditolak bila skornya mencapai ambang, yang bawaannya 5 untuk request masuk dan 4 untuk respons. Jadi satu kecocokan CRITICAL sudah cukup untuk memblokir.

Paranoia level (PL) menentukan seberapa banyak aturan yang aktif:

- **PL 1**: keamanan dasar dengan kebutuhan penyetelan minimal. Cocok untuk server apa pun yang terbuka ke internet.
- **PL 2**: untuk data pengguna nyata, misalnya toko online. Ada salah blokir yang perlu disetel.
- **PL 3**: tingkat keamanan setara perbankan online, dengan banyak salah blokir.
- **PL 4**: paling ketat, untuk aset paling berharga, dengan risiko salah blokir tinggi.

Di CRS v4, levelnya diatur lewat `tx.blocking_paranoia_level` di `crs-setup.conf`. Ada juga `tx.detection_paranoia_level`: aturan sampai level ini dijalankan dan dicatat, tapi hanya aturan sampai level blokir yang ikut menentukan penolakan. Ini cara aman mengintip dampak PL lebih tinggi sebelum menaikkannya.

## Langkah 5: setel salah blokir dengan pengecualian

Biarkan DetectionOnly berjalan beberapa hari dengan trafik nyata. Lalu baca audit log dan cari pola: aturan apa (ID-nya) yang memicu, di path apa, pada parameter apa.

Jangan mematikan aturan secara global hanya karena satu halaman bermasalah. Buat pengecualian sesempit mungkin, misalnya mengecualikan satu aturan untuk satu parameter di satu path. CRS menyediakan plugin pengecualian untuk aplikasi populer; untuk WordPress, misalnya, ada wordpress-rule-exclusions-plugin di GitHub CoreRuleSet.

Dokumentasi CRS memperbolehkan menaikkan ambang anomali sementara selama masa penyetelan, tapi mengingatkan bahwa ambang di atas bawaan dalam jangka panjang bisa membuat serangan lolos. Targetnya tetap ambang 5.

## Langkah 6: aktifkan blokir dan pantau

Setelah audit log bersih dari pengguna sah, ubah ke:

```apache
SecRuleEngine On
```

Pantau log galat dan audit log secara rutin, terutama setelah update aplikasi, plugin, atau CRS. Fitur baru di aplikasi sering memicu aturan yang sebelumnya diam. Simpan semua pengecualianmu dalam file terpisah agar tidak tertimpa saat CRS diperbarui.

WAF di server melengkapi, bukan menggantikan, pembaruan aplikasi. Bila menemukan pola serangan yang berhasil lolos, temuan itu justru pertanda perlu audit lebih dalam seperti dibahas di [SOC, vulnerability scan, dan pentest](https://nivelva.com/insight/soc-vulnerability-scan-pentest).

## Ringkasan pilihan

| Pilihan | Cocok untuk | Catatan |
|:--|:--|:--|
| ModSecurity v2 + CRS | Apache | Modul Apache |
| ModSecurity v3 + CRS | Nginx | Butuh konektor ModSecurity-nginx |
| Coraza + CRS | Caddy, Envoy (Traefik dan HAProxy masih eksperimental) | Go, 100% kompatibel CRS v4 menurut proyeknya |
| Paranoia level 1 | Hampir semua website | Titik awal yang dianjurkan |
| Paranoia level 2 | Toko online, data pelanggan | Siapkan waktu penyetelan |
| Paranoia level 3 sampai 4 | Data sangat sensitif | Banyak salah blokir, butuh tim yang siap |

## Pertanyaan yang sering diajukan

### Apakah ModSecurity membuat website lambat?

Setiap request diperiksa, jadi ada beban tambahan yang besarnya tergantung trafik, jumlah aturan aktif, dan paranoia level. Ukur di servermu sendiri sebelum dan sesudah mengaktifkan, terutama di PL lebih tinggi.

### Berapa lama mode DetectionOnly sebaiknya dijalankan?

Tidak ada angka baku. Jalankan sampai semua alur penting (login, checkout, form, editor admin) sudah dilalui pengguna nyata dan lognya bersih dari salah blokir.

### Apakah CRS bisa melindungi plugin yang punya celah?

CRS menahan banyak pola serangan generik, tapi bukan pengganti patch. Celah logika atau celah yang tidak memakai pola umum bisa tetap lolos.

### Bolehkah ModSecurity dipakai bersama Cloudflare?

Boleh. Cloudflare menyaring di tepi jaringan, ModSecurity memeriksa di server asal. Pastikan log ModSecurity mencatat IP asli pengunjung, bukan IP Cloudflare.

Checklist sebelum mengaktifkan blokir:

- Mesin WAF sesuai web server sudah terpasang dan dimuat.
- CRS dimuat dari rilis resmi, `crs-setup.conf` sudah disesuaikan.
- DetectionOnly sudah berjalan dengan trafik nyata.
- Pengecualian disimpan di file terpisah dan sesempit mungkin.
- Ambang anomali kembali ke 5 sebelum `SecRuleEngine On`.

## Sumber

- <https://github.com/owasp-modsecurity/ModSecurity>
- <https://github.com/owasp-modsecurity/ModSecurity/releases>
- <https://github.com/coreruleset/coreruleset/releases>
- <https://coreruleset.org/docs/2-how-crs-works/2-1-anomaly_scoring/>
- <https://coreruleset.org/docs/2-how-crs-works/2-2-paranoia_levels/>
- <https://github.com/corazawaf/coraza>
- <https://github.com/coreruleset/wordpress-rule-exclusions-plugin>

---

Diterbitkan oleh Nivelva Insight (https://nivelva.com/insight/). Artikel ini: https://nivelva.com/insight/modsecurity-owasp-crs
Kontak Nivelva: WhatsApp https://wa.me/6285111245007, email hello@nivelva.com