# Seni Regular Expression Tingkat Lanjut untuk WAF & Log Analysis

> Diterbitkan oleh Literally Web ID pada 21 Oct 2026
> Sumber: https://literally.web.id/articles/seni-regular-expression-tingkat-lanjut-untuk-waf-log-analysis

---

## 1. Titik Awal Masalah: Mengapa Arsitektur Lama Sering Ambruk di Produksi

Ingatkah Anda malam ketika pager berdering pukul 02:30 pagi, dan dashboard Grafana menyala merah menyala seperti pohon natal? Waktu itu, klaster Nginx di depan aplikasi Go kami mendadak lumpuh total. CPU melonjak ke 100%, bukan karena lonjakan traffic sah dari marketing, melainkan karena seseorang mengirimkan payload injeksi SQL yang sangat licik melalui header HTTP `User-Agent`.

Masalahnya bukan pada serangan itu sendiri—sebagai engineer infrastruktur, kita sudah kenyang menghadapi serangan harian. Masalahnya terletak pada satu baris pola Regular Expression di ModSecurity yang bertindak sebagai gerbang pengaman. Pola itu tampak tidak berbahaya saat diuji di laptop lokal menggunakan `grep`, tapi ketika berhadapan dengan jutaan request per detik di lingkungan produksi, ia berubah menjadi bom waktu: *Catastrophic Backtracking*.

Di dunia nyata, kita tidak hidup di ruang steril lab komputer. Kita hidup di mana arsitektur web modern melibatkan cloudflare di edge, Nginx sebagai reverse proxy, backend Go atau PHP-FPM, hingga log shipper seperti Filebeat yang menyedot log akses ke basis data analitik. Ketika regex salah diracik, ia tidak hanya meloloskan celah keamanan, tapi juga bisa membuat seluruh sistem berlutut karena kehabisan sumber daya CPU.

Mari kita bedah bagaimana cara meracik senjata paling ampuh sekaligus paling mematikan ini agar bekerja untuk kita, bukan menghancurkan kita dari dalam.

## 2. Di Balik Layar: Bagaimana Sistem Ini Bekerja Tanpa Sihir

Sebelum kita masuk ke sintaks yang membuat pusing, kita harus paham betul apa yang terjadi di dalam mesin ketika sebuah regex dieksekusi oleh mesin PCRE2 (Perl Compatible Regular Expressions) yang mengotori WAF seperti ModSecurity atau utility analitik log seperti `sed` dan `awk`.

Secara mendasar, mesin regex bekerja menggunakan salah satu dari dua pendekatan: *Deterministic Finite Automaton* (DFA) atau *Non-deterministic Finite Automaton* (NFA). Sebagian besar bahasa pemrograman modern dan tool keamanan menggunakan NFA karena kemampuannya menangani fitur kompleks seperti *backreferences* dan *lookarounds*.

Namun, kelemahan terbesar NFA adalah sifatnya yang mencoba mencocokkan pola dengan cara mencoba berbagai kemungkinan jalur secara rekursif (trial and error). Jika kita menulis pola seperti `(a+)+b` dan memberikannya string `aaaaaaaaaaaaaaaaaaaaac` (tanpa huruf `b` di akhir), mesin NFA akan mencoba jutaan kombinasi pemecahan kelompok `a` sebelum akhirnya menyerah. Di sinilah *Catastrophic Backtracking* terjadi.

> [!WARNING]
> Jangan pernah menggunakan kuantifikator bersarang (nested quantifiers) seperti `(a*)*` atau kombinasi *alternation* yang tumpang tindih seperti `(a|ab)+` pada data input yang tidak terpercaya (user-supplied input) di WAF.

Bayangkan regex Anda seperti seorang petugas keamanan bandara yang memeriksa koper satu per satu dengan metode tebak-tebakan acak alih-alih menggunakan mesin X-ray terstruktur. Semakin rumit pola yang Anda buat tanpa batas yang jelas, semakin lama waktu yang dibutuhkan untuk mengambil keputusan, memblokir antrean request yang sah, dan akhirnya melumpuhkan worker web server Anda.

## 3. Pilihan Pendekatan & Kompromi yang Harus Diambil

Dalam merancang sistem pertahanan WAF dan analisis log, kita selalu dihadapkan pada trilema klasik: **Keamanan (Security)**, **Performa (Performance)**, dan **Ketepatan (Accuracy)**. Anda tidak bisa mendapatkan ketiganya secara maksimal tanpa kompromi.

Mari kita bandingkan dua pendekatan ekstrem yang sering saya temui di lapangan:

| Parameter | Pendekatan A: Naive & Broad Regex | Pendekatan B: Hardened & Anchored Regex |
| :--- | :--- | :--- | 
| **Contoh Pola** | `.*(union|select|drop).*` | `(?:unions+(?:alls+)?select|selects+.*s+from)` |
| **Risiko False Positive** | Tinggi (memicu kata 'selection' atau 'unions') | Rendah (disertai word boundary dan konteks ketat) |
| **Kompleksitas CPU** | Rendah secara teori, tapi memicu backtracking pada string panjang | Terkontrol, prediktif, dan memiliki batas langkah eksekusi | 
| **Efektivitas WAF** | Buruk (mudah di-bypass dengan pengkodean URL atau komentar SQL) | Tinggi (mengenali struktur semantik serangan) |

Sebagai arsitek, pilihan kita jatuh pada Pendekatan B. Kita lebih baik sedikit lelah di awal merumuskan regex yang ketat daripada harus menanggung kerugian akibat *False Positive* yang memblokir transaksi pelanggan VIP atau mengalami *False Negative* yang membocorkan tabel basis data.

## 4. Meracik Lingkungan: Persiapan & Prasyarat Lapangan

Sebelum kita menulis kode, mari kita siapkan laboratorium mini kita. Kita asumsikan Anda menggunakan tumpukan infrastruktur berbasis Linux (Ubuntu 22.04 LTS atau Debian 12), Nginx sebagai reverse proxy, ModSecurity v3 (libmodsecurity), dan tool analisis log standar seperti `grep`, `sed`, serta `awk`.

Mari instal dependensi yang diperlukan untuk kompilasi modul dan pengujian:

```bash
# Perbarui daftar paket sistem
sudo apt update && sudo apt upgrade -y

# Instal tool esensial untuk analisis log dan debugging regex
sudo apt install -y build-up libpcre2-dev nginx libmodsecurity3 libmodsecurity-dev

# Verifikasi versi PCRE2 yang mendukung mesin regex modern
pcre2-config --version
```

Pastikan juga Anda memiliki direktori khusus untuk eksperimen aturan WAF kustom di `/etc/nginx/modsec/rules/` agar tidak merusak konfigurasi global yang sudah berjalan di produksi.

## 5. Langkah Implementasi: Membangun Solusi yang Tangguh

Sekarang mari kita buat aturan ModSecurity nyata yang bertugas menangkap upaya injeksi SQL tingkat lanjut pada parameter GET dan POST, namun tetap aman dari jebakan performa.

Buat file konfigurasi baru di `/etc/nginx/modsec/rules/custom-sql-injection.conf`:

```nginx
# ------------------------------------------------------------------
# Custom WAF Rule: Deteksi SQL Injection Aman Backtracking
# Dibuat dengan pendekatan Non-Backtracking/Atomic Grouping (jika didukung)
# ------------------------------------------------------------------

SecRule ARGS "@rx (?i)\b(union\s+(?:all\s+)?select|select\s+.+?\bfrom\b|insert\s+into.+?\bvalues\b|update\s+.+?\bset\b|delete\s+from\b)\b" \
    "id:10001,"\
    "phase:2,"\
    "deny,"\
    "status:403,"\
    "log,"\
    "msg:'Potential SQL Injection Detected via Custom Regex',"\
    "tag:'APPLICATION-ATTACK-SQLi',"\
    "severity:'CRITICAL'"

# Aturan pelengkap untuk memantau anomali pada User-Agent
SecRule REQUEST_HEADERS:User-Agent "@rx (?i)(sqlmap|nikto|nmap|masscan)" \
    "id:10002,"\
    "phase:1,"\
    "drop,"\
    "log,"\
    "msg:'Automated Scanner Detected in User-Agent',"\
    "tag:'AUTOMATION-TOOL'"
```

> [!TIP]
> Penggunaan modifier `(?i)` di awal regex membuat pencocokan menjadi *case-insensitive* tanpa harus membuang sumber daya tambahan untuk mengubah string input menjadi huruf kecil terlebih dahulu.

Integrasikan file aturan tersebut ke dalam konfigurasi utama ModSecurity Anda (` /etc/nginx/modsec/main.conf`):

```nginx
# Sertakan aturan kustom kita
Include /etc/nginx/modsec/rules/custom-sql-injection.conf
```

Uji konfigurasi Nginx Anda untuk memastikan tidak ada kesalahan sintaks:

```bash
sudo nginx -t
sudo systemctl reload nginx
```

## 6. Membedah Baris Kode Krusial yang Kerap Menjebak

Mari kita bedah regex krusial yang kita gunakan di atas bagian per bagian:

`\b(union\s+(?:all\s+)?select|select\s+.+?\bfrom\b)\b`

1. **`\b` (Word Boundary):** Ini adalah penyelamat hidup performa Anda. Alih-alih membiarkan mesin memeriksa setiap karakter di tengah kata (misalnya kata *'unional'* atau *'selectionist'*), `\b` memaksa mesin hanya memulai pencocokan pada batas kata. Ini memangkas iterasi yang tidak perlu.
2. **Non-capturing group `(?:... )`:** Ketika kita menulis `(?:all\s+)?`, kita memberi tahu mesin regex untuk tidak menyimpan hasil tangkapan grup tersebut ke dalam memori stack. Ini menghemat alokasi memori secara signifikan saat memproses jutaan request.
3. **Lazy quantifier `.+?`:** Perhatikan tanda tanya setelah tanda plus (`+?`). Ini adalah sifat *lazy* (malas) yang memerintahkan mesin untuk berhenti mencocokkan karakter segera setelah kata kunci berikutnya (`from`) ditemukan. Tanpa tanda tanya ini (`.+`), mesin akan bersifat *greedy* (rakus)—memakan seluruh sisa kalimat lalu mundur perlahan (*backtracking*), yang menjadi akar dari bencana performa.

## 7. Bertahan di Bawah Tekanan: Skenario Traffic Nyata

Bagaimana jika serangan datang bukan dari satu IP, melainkan dari botnet terdistribusi yang menyamar menggunakan ribuan proksi? Di sinilah kita beralih dari WAF ke analisis log server secara *real-time* menggunakan kombinasi `grep`, `sed`, dan `awk` langsung di terminal server.

Misalkan Anda ingin mendeteksi pola serangan injeksi yang lolos dari WAF dengan memindai log akses Nginx (`/var/log/nginx/access.log`) secara *live*:

```bash
# Memantau log akses secara real-time dan menyaring pola UNION SELECT yang mencurigakan
tail -f /var/log/nginx/access.log | grep --line-buffered -E "UNION[[:space:]]+SELECT" | awk '{print $1, $7, $9}'
```

Jika Anda perlu membersihkan log lama dari artefak parameter sensitif sebelum dikirim ke sistem penyimpanan S3 atau Elasticsearch (proses *log sanitization*), gunakan `sed` dengan regex yang aman:

```bash
# Menyensor token atau password yang tidak sengaja tercatat di query string log
sed -E 's/(password|token)=([^& ]*)/
=REDACTED/g' /var/log/nginx/access.log > /var/log/nginx/access_sanitized.log
```

Pendekatan ini memastikan kepatuhan terhadap standar keamanan data (seperti GDPR atau PCI-DSS) tanpa mengorbankan visibilitas debug backend Anda.

## 8. Jebakan Klasik & Cara Menghindarinya Sebelum Meledak

Selama bertahun-tahun membimbing para junior engineer, saya melihat pola kesalahan yang sama berulang kali. Berikut adalah daftar dosa besar dalam penulisan regex untuk infrastruktur:

* **Dosa 1: Menggunakan `.*` di awal dan akhir pola.** 
  Contoh buruk: `.*admin.*`. Pola ini memaksa mesin mencoba mencocokan dari setiap posisi karakter yang memungkinkan. Selalu gunakan jangkar seperti `^` (awal baris) atau `\b` (batas kata).
* **Dosa 2: Mengabaikan Encoding Bypass.** 
  Penyerang sering menggunakan URL encoding (`%27` untuk tanda kutip tunggal) atau Unicode. Pastikan WAF Anda melakukan normalisasi (dekode) input *sebelum* aturan regex dieksekusi.
* **Dosa 3: Mengandalkan Regex sebagai Satu-satunya Benteng Keamanan.** 
  Regex di WAF adalah pertahanan lapis kedua (compensating control). Pertahanan utama tetap harus berada di level kode aplikasi menggunakan *Prepared Statements* atau *Parameterized Queries* pada basis data.

## 9. Uji Nyali: Mengukur Performa di Titik Batas

Jangan pernah mempercayai regex sebelum Anda mengujinya di bawah tekanan stres tes. Kita bisa menggunakan tool utilitas bawaan seperti `pcre2test` untuk mengukur berapa banyak siklus CPU yang dihabiskan oleh pola kita.

Buat file uji bernama `test_patterns.txt`:

```text
/\b(union\s+(?:all\s+)?select)\b/i
    GET /index.php?id=1+UNION+SELECT+null,null-- HTTP/1.1
    GET /index.php?id=1+unionalselections+null,null-- HTTP/1.1
```

Jalankan pengujian menggunakan utilitas PCRE2:

```bash
pcre2test test_patterns.txt
```

Perhatikan metrik waktu eksekusi yang dikembalikan. Jika sebuah pola membutuhkan waktu lebih dari beberapa milidetik untuk string sepanjang 100 karakter, buang pola tersebut dan tulis ulang dengan batasan yang lebih ketat.

## 10. Catatan Lapangan & Checklist Sebelum Rilis

Sebelum Anda menekan tombol *merge* pada *Pull Request* aturan keamanan ini ke repositori Git utama dan menerapkannya ke produksi, jalankan checklist terakhir ini:

1. [ ] Apakah semua kuantifikator (`+`, `*`, `{n,m}`) sudah diuji terhadap string input yang sangat panjang (stress test string > 10kb)?
2. [ ] Apakah aturan sudah diuji dalam mode `DetectionOnly` (audit mode) di ModSecurity selama minimal 3 hari untuk memastikan tidak ada *False Positive* pada traffic sah?
3. [ ] Apakah penggunaan *word boundary* (`\b`) sudah diterapkan secara konsisten untuk menghindari pencocokan parsial yang memicu blokir salah?
4. [ ] Apakah tim on-call sudah diberi tahu mengenai aturan baru ini beserta prosedur penanganan cepat (rollback) jika terjadi anomali layanan?

Infrastruktur yang handal bukanlah infrastruktur yang tidak pernah diserang, melainkan infrastruktur yang tahu persis cara menangkis serangan tanpa mengorbankan performa dan kewarasan pengelolanya di tengah malam.