Suricata Custom Rules Lab
3 VM (Kali attacker, target, Suricata sensor trên bridge br0). Cùng một bộ tấn công được chạy lại hai lần: chỉ rule mặc định, rồi thêm 88 rule tự viết.
Setup
3 scenario, cùng attack profile, so trực tiếp.
- Scenario 1 (baseline): chỉ default rules (~30,000), 500 port scan + 100 SQLi + 50 SSH brute → 54 alerts.
- Scenario 2 (enhanced): default + 88 custom rules (~47,324 tổng), cùng attack profile → 486 alerts.
- Scenario 3 (benign): traffic bình thường (ping, HTTP, SSH login hợp lệ) để đo false positive.
Evidence
Alert tăng 9×, nhưng đó không phải thước đo chất lượng.
88 rule, nhưng chỉ 16 rule thật sự bắn.
Kết quả scenario 2 chỉ nêu tên 4 SID đã bắn (SID 1000001 TCP SYN scan, SID 1000015 Sequential port scan, SID 1000111 SQL OR 1=1, SID 1000301 SSH multiple attempts). Grid dưới hiển thị cả 88 rule theo đúng SID thật trong repo — ô nào không có tên trong kết quả thì để trống, không đoán.
Di chuột hoặc bấm vào một ô để xem SID.
MITRE ATT&CK mapping — theo category, không có trong metadata rule.
Scope trung thực: repo không gắn metadata: mitre_technique_id vào rule nào (grep "T1" trong file .rules = 0 kết quả). Mapping T1595/T1190/T1110/T1046 dưới đây do tự gán theo category tên rule, chưa phải dữ liệu có sẵn trong repo.
| Technique | Tactic | Rule category | Rules |
|---|---|---|---|
| T1595 / T1046 | Reconnaissance / Discovery | portscan | 17 |
| T1190 | Initial Access | sqli, exploits | 28 + 17 |
| T1110 | Credential Access | bruteforce | 26 |
What I learned
Alert count không phải detection rate.
Viết rule dễ hơn validate rule. Một con số "+800% alert" nghe ấn tượng, nhưng nếu không tách được true positive khỏi false positive thì nó chỉ làm tăng khối lượng cho người trực SOC. Lần tới mình sẽ log rõ SID nào bắn ở mỗi test để không phải suy đoán 84/88 rule còn lại.
Scope trung thực: 3 VM, mỗi scenario chạy 1 lần, không lặp lại để đo phương sai. Alert ≠ attack đã bị chặn — Suricata ở chế độ IDS (log), không phải IPS (block) trong lab này.