Panduan Suricata: Network IDS/IPS untuk Linux di 2026

Diperbarui: 29 Mei 2026

Suricata adalah engine Network IDS/IPS dan Network Security Monitoring open source yang mengurai trafik secara real-time, mencocokkannya dengan ribuan rule, lalu menghasilkan event berformat EVE JSON yang siap dikonsumsi SIEM. Di 2026, Suricata 7.0.x adalah baseline produksi: multi-threaded, mendukung af-packet zero-copy, NFQUEUE untuk mode inline (IPS), serta inspeksi TLS/JA3/JA4 untuk trafik terenkripsi. Panduan ini akan memandu Anda dari instalasi sampai tuning blast-radius di server Linux produksi, berdasarkan pengalaman saya men-deploy Suricata di beberapa lingkungan high-traffic.

• Suricata 7.0.7 (rilis 2026) adalah versi stabil dengan dukungan QUIC v1, JA4 fingerprinting, dan datasets yang lebih cepat.
• Mode af-packet cocok untuk IDS pasif via SPAN/TAP, sedangkan mode nfqueue dipadukan dengan nftables untuk IPS inline.
• Ruleset utama: Emerging Threats Open (gratis), dikelola via suricata-update setiap 24 jam.
• Output eve.json dipipe ke Filebeat lalu ke Elasticsearch atau Wazuh untuk korelasi event.
• Tuning produksi wajib: pin CPU per worker, aktifkan RSS pada NIC, dan batasi stream.memcap sesuai RAM yang tersedia.
• Threat model: Suricata melihat lapisan jaringan, bukan host. Pasangkan dengan auditd atau Wazuh untuk visibility penuh.

Apa itu Suricata dan kapan menggunakannya?

Suricata adalah engine deteksi jaringan open source yang dikembangkan oleh Open Information Security Foundation (OISF). Berbeda dari firewall yang cuma melihat header paket, Suricata melakukan deep packet inspection (DPI), merekonstruksi stream TCP, mem-parsing protokol aplikasi (HTTP, TLS, DNS, SMB, Kerberos, QUIC, MQTT), lalu mencocokkan rule berbasis konten. Dari sudut pandang threat model, Suricata menutup sisi east-west dan north-south traffic yang tidak bisa ditangkap oleh agen host seperti auditd atau Falco.

Pertanyaan yang biasanya saya ajukan sebelum memutuskan deploy Suricata sederhana: "Apa yang pecah duluan kalau attacker masuk?" Kalau jawabannya "tidak ada yang melihat traffic C2 ke luar," maka Suricata di posisi egress wajib. Kalau jawabannya "tidak ada yang melihat lateral movement antar VLAN," maka SPAN port di core switch plus Suricata IDS adalah investasi blast-radius paling murah dibanding XDR komersial. Honestly, saya pernah hampir kena audit gara-gara kasus kedua, jadi pelajaran ini cukup mahal.

Use case khas yang sering saya temui:

• Edge monitoring. Suricata duduk di belakang firewall perimeter untuk mendeteksi exploit attempt dan beacon C2.
• Cloud VPC monitoring. Suricata di EC2/GCE dengan VPC traffic mirroring atau Gateway Load Balancer.
• Compliance. PCI DSS 4.0 requirement 11.5 (intrusion detection) dan ISO 27001 A.12.4 (logging) terpenuhi dengan Suricata plus retensi EVE JSON 90 hari.
• Incident response. Replay PCAP via suricata -r capture.pcap untuk forensik post-incident.

Suricata vs Snort vs Zeek: mana yang tepat?

Tiga engine ini sering dibandingkan karena overlap fungsional, tapi filosofinya berbeda jauh. Snort 3 (Cisco Talos) adalah signature-based IDS klasik. Suricata adalah signature-based plus protocol parsing plus scripting (Lua). Zeek (dulu Bro) adalah engine event/scripting yang fokus pada metadata, bukan rule matching. Tabel berikut merangkum dimensi yang biasanya jadi pertimbangan tim SOC.

Dimensi	Suricata 7	Snort 3	Zeek 6
Model deteksi	Signature + protocol + Lua	Signature-only	Event scripting
Multi-threading	Native, scalable ke 40+ core	Native (sejak v3)	Single-process, cluster manual
IPS inline	NFQUEUE, AF_PACKET IPS	DAQ inline	Tidak (NSM-only)
Ruleset gratis	ET Open, Talos LightSPD	Talos Community	Tidak applicable
Output JSON	EVE JSON native	Plugin alert_json	JSON via plugin
Learning curve	Sedang	Sedang	Tinggi (bahasa script sendiri)
Use case ideal	IDS/IPS umum, SOC modern	Compatibility dengan rule legacy	Forensik dan threat hunting

Rekomendasi saya: Suricata untuk mayoritas deployment baru. Snort masih masuk akal kalau Anda terikat ke Cisco/Talos commercial subscription. Zeek dipakai sebagai pelengkap (bukan pengganti) ketika tim sudah punya analis yang nyaman menulis script .zeek untuk hunting custom.

Instalasi Suricata 7 di Ubuntu 24.04 dan RHEL 9

Versi distro biasanya tertinggal 1 sampai 2 minor di belakang upstream. Untuk produksi, saya selalu pakai OISF PPA (Ubuntu) atau EPEL (RHEL/Rocky/Alma) supaya dapat backport security fix tepat waktu.

Ubuntu 24.04 LTS

# Tambahkan PPA resmi OISF
sudo add-apt-repository ppa:oisf/suricata-stable
sudo apt update
sudo apt install -y suricata jq

# Verifikasi versi (target 7.0.7+)
suricata --build-info | head -n 5

# Aktifkan service
sudo systemctl enable --now suricata

RHEL 9 / Rocky Linux 9

# Install EPEL repo dan Suricata
sudo dnf install -y epel-release
sudo dnf install -y suricata suricata-update jq

# Identifikasi interface yang akan dipantau
ip -br link show

# Edit konfigurasi default interface
sudo sed -i 's/interface: eth0/interface: ens192/g' /etc/suricata/suricata.yaml

sudo systemctl enable --now suricata

Konfigurasi mode IDS dengan af-packet

Mode default Suricata adalah pasif (IDS) memakai af-packet, socket Linux yang memungkinkan zero-copy packet capture dengan dukungan multi-thread melalui cluster_flow. Konfigurasi ini direkomendasikan untuk 95% deployment karena tidak menambah latensi dan tidak berisiko menjatuhkan trafik produksi kalau Suricata crash.

Edit bagian af-packet di /etc/suricata/suricata.yaml:

af-packet:
  - interface: ens192
    # Satu thread per CPU core fisik
    threads: auto
    # Distribusi flow merata antar thread
    cluster-id: 99
    cluster-type: cluster_flow
    # Zero-copy via PACKET_MMAP v3
    use-mmap: yes
    mmap-locked: yes
    tpacket-v3: yes
    # Ring buffer 64MB per thread
    ring-size: 200000
    block-size: 1048576
    # Mode pasif (IDS)
    copy-mode: none
    defrag: yes
    checksum-checks: auto

Untuk mempercepat startup, matikan engine yang tidak Anda pakai. Misalnya kalau Anda tidak inspeksi MQTT atau Modbus:

app-layer:
  protocols:
    mqtt:
      enabled: no
    modbus:
      enabled: no
    dnp3:
      enabled: no

Restart lalu validasi:

sudo suricata -T -c /etc/suricata/suricata.yaml -v
sudo systemctl restart suricata
sudo tail -f /var/log/suricata/suricata.log

Mode IPS inline dengan nftables NFQUEUE

Untuk mode aktif (IPS), Suricata harus duduk di path paket dan men-DROP traffic yang match. Cara paling stabil di kernel modern adalah NFQUEUE, di mana paket di-queue oleh netfilter ke userspace, Suricata memutuskan ACCEPT/DROP, lalu paket dilanjutkan. Pendekatan ini menyatu rapi dengan konfigurasi firewall nftables yang sudah Anda miliki.

Aturan nftables minimal untuk mengirim traffic forward ke queue 0 sampai 3 (4 worker):

table inet filter {
    chain forward {
        type filter hook forward priority 0; policy accept;
        # Lewati trafik internal management
        ip saddr 10.0.0.0/24 accept
        # Kirim sisanya ke Suricata
        counter queue num 0-3 fanout
    }
}

Lalu di suricata.yaml aktifkan nfqueue:

nfq:
  mode: accept
  repeat-mark: 1
  repeat-mask: 1
  route-queue: 2
  batchcount: 20
  fail-open: yes

Jalankan Suricata dalam mode IPS:

sudo suricata -q 0 -q 1 -q 2 -q 3 -c /etc/suricata/suricata.yaml --user suricata

Manajemen ruleset Emerging Threats Open

Ruleset adalah jantung deteksi. Tool resmi suricata-update mengelola sumber rule, kompilasi, dan reload. Sumber default adalah Emerging Threats Open yang diupdate harian dan mencakup sekitar 50.000 signature gratis. Untuk fingerprint TLS jahat, sumber Abuse.ch SSL Blacklist juga sangat berguna.

# List sumber rule yang tersedia
sudo suricata-update list-sources

# Aktifkan ET Open (default sudah aktif)
sudo suricata-update enable-source et/open

# Tambahkan source SSL bad fingerprint (Abuse.ch)
sudo suricata-update enable-source sslbl/ssl-fp-blacklist
sudo suricata-update enable-source sslbl/ja3-fingerprints

# Download & compile
sudo suricata-update

# Reload tanpa restart (zero-downtime)
sudo suricatasc -c reload-rules

Otomatisasi via systemd timer (lebih bersih dari cron):

# /etc/systemd/system/suricata-update.service
[Unit]
Description=Update Suricata rules

[Service]
Type=oneshot
ExecStart=/usr/bin/suricata-update --quiet
ExecStartPost=/usr/bin/suricatasc -c reload-rules

# /etc/systemd/system/suricata-update.timer
[Unit]
Description=Daily Suricata rules update

[Timer]
OnCalendar=daily
RandomizedDelaySec=30m
Persistent=true

[Install]
WantedBy=timers.target

Untuk menonaktifkan rule yang menghasilkan false positive di lingkungan Anda, gunakan file /etc/suricata/disable.conf dengan SID atau regex, lalu jalankan ulang suricata-update. Jangan pernah mengedit file .rules langsung, karena perubahan Anda akan tersapu pada update berikutnya.

Pipeline EVE JSON ke SIEM

Output utama Suricata adalah /var/log/suricata/eve.json, satu event per baris, semua tipe (alert, http, dns, tls, flow, fileinfo) dalam satu stream. Format ini sengaja didesain supaya gampang dipipe ke Elasticsearch, OpenSearch, Wazuh, atau Splunk.

Contoh event alert (dipersingkat):

{
  "timestamp": "2026-05-29T03:14:22.481Z",
  "flow_id": 1882938472,
  "event_type": "alert",
  "src_ip": "203.0.113.42",
  "src_port": 51422,
  "dest_ip": "10.0.1.15",
  "dest_port": 22,
  "proto": "TCP",
  "alert": {
    "signature_id": 2019876,
    "signature": "ET SCAN Potential SSH Scan",
    "category": "Attempted Information Leak",
    "severity": 2
  }
}

Filebeat config minimal untuk shipping ke Elasticsearch 8.x via Filebeat:

# /etc/filebeat/filebeat.yml
filebeat.inputs:
  - type: filestream
    id: suricata-eve
    paths:
      - /var/log/suricata/eve.json
    parsers:
      - ndjson:
          target: ""
          add_error_key: true

output.elasticsearch:
  hosts: ["https://elastic.internal:9200"]
  api_key: "${ES_API_KEY}"
  index: "suricata-%{+yyyy.MM.dd}"

Kalau Anda sudah memakai Wazuh untuk korelasi event host-level (lihat panduan auditd untuk forensik dan compliance), tambahkan saja blok localfile Wazuh untuk membaca eve.json. Decoder dan rule Suricata sudah built-in di Wazuh 4.7+.

Tuning performa untuk trafik tinggi

Di trafik di atas 1 Gbps, default Suricata mulai drop paket. Pertanyaan yang harus Anda jawab: "Berapa banyak drop yang acceptable sebelum saya kehilangan visibility?" Saya pribadi targetkan <0.01% drop pada peak. Saya pernah hit batas ini di project sebelumnya ketika trafik HTTP mendadak naik 3x karena event marketing, jadi headroom itu penting.

1. CPU pinning dan RSS

Distribusikan worker thread Suricata ke core spesifik dan aktifkan Receive Side Scaling di NIC:

# Cek jumlah RSS queue
sudo ethtool -l ens192

# Set ke jumlah core fisik (bukan hyperthread)
sudo ethtool -L ens192 combined 8

# Disable offloading yang mengganggu DPI
sudo ethtool -K ens192 gro off lro off tso off gso off

Di suricata.yaml, set CPU affinity:

threading:
  set-cpu-affinity: yes
  cpu-affinity:
    - worker-cpu-set:
        cpu: [ 2,3,4,5,6,7,8,9 ]
        mode: "exclusive"
        prio:
          default: "high"

2. Memcap dan hyperscan

Pattern matching default (Aho-Corasick) lebih lambat dari Hyperscan. Pada CPU Intel/AMD modern, aktifkan:

mpm-algo: hs
spm-algo: hs

stream:
  memcap: 8gb
  checksum-validation: no
  inline: no
  reassembly:
    memcap: 4gb

3. Monitoring drop rate

# Snapshot statistik
sudo suricatasc -c "iface-stat ens192" | jq

# Cari capture.kernel_drops di stats.log
grep -E "kernel_drops|kernel_packets" /var/log/suricata/stats.log | tail -20

Kalau drop rate di atas 1%, naikkan ring-size di af-packet, tambah core di worker-cpu-set, atau buang inspeksi protokol yang tidak perlu. So, urutan biasanya: ring buffer dulu, baru core, baru protokol.

Troubleshooting drop dan false positive

Dua sumber masalah paling sering: paket drop di kernel dan alert yang berisik. Threat model di sini sederhana: false negative jauh lebih mahal daripada false positive, tapi false positive yang dibiarkan akan membuat tim SOC mematikan alert legitim. Jadi kebersihan ruleset itu bukan kosmetik, tapi syarat agar tim percaya pada sistemnya.

Drop tinggi tapi CPU rendah: hampir selalu masalah ring buffer atau NIC offload. Cek ethtool -S ens192 | grep -i drop lalu naikkan ring-size.

CPU 100% di satu thread saja: berarti cluster_flow hashing tidak merata, biasanya karena traffic didominasi satu pasangan IP. Coba cluster-type: cluster_qm (queue mapping) kalau NIC mendukung.

Alert spam dari satu signature: identifikasi SID via jq '.alert.signature_id' eve.json | sort | uniq -c | sort -rn | head, lalu tambahkan ke /etc/suricata/disable.conf:

# Disable rule spesifik
2019876
# Atau group ET INFO
group:emerging-info.rules

Pertanyaan yang sering diajukan

Apakah Suricata IDS atau IPS?

Keduanya. Suricata default berjalan sebagai IDS pasif (af-packet, copy-mode none) yang hanya menghasilkan alert. Untuk IPS aktif yang men-drop traffic, jalankan dalam mode NFQUEUE dengan integrasi nftables atau iptables. Pilih mode berdasarkan toleransi risiko: IDS aman secara availability, IPS lebih agresif tapi berisiko false positive memblokir traffic legitim.

Apa perbedaan Suricata dan Snort?

Suricata native multi-threaded sejak hari pertama dan menghasilkan EVE JSON terstruktur, sedangkan Snort 3 baru menambahkan multi-threading dan masih lebih populer untuk integrasi commercial Cisco Talos. Suricata juga mengurai protokol aplikasi lebih banyak (TLS JA4, QUIC, MQTT) dan mendukung Lua scripting. Untuk deployment baru di 2026, Suricata umumnya pilihan lebih baik.

Bagaimana cara update rule Suricata?

Gunakan sudo suricata-update diikuti sudo suricatasc -c reload-rules untuk reload tanpa restart. Otomatisasi via systemd timer harian dengan RandomizedDelaySec untuk menyebar load. Jangan edit file .rules langsung; gunakan /etc/suricata/disable.conf dan enable.conf untuk customization.

Apakah Suricata bisa inspeksi traffic terenkripsi TLS?

Suricata tidak mendekripsi TLS tanpa MitM proxy, tetapi bisa menganalisis metadata: SNI, sertifikat, JA3/JA4 fingerprint client/server, dan pola timing. Banyak malware C2 punya JA3/JA4 unik yang dapat di-blacklist via SSL BL feed. Untuk decryption penuh, deploy sebelum reverse proxy yang melakukan TLS termination.

Berapa kebutuhan hardware untuk Suricata di trafik 10 Gbps?

Sebagai patokan kasar: 1 core fisik per 1 sampai 1.5 Gbps trafik dengan Hyperscan dan ET Open ruleset, 32 sampai 64 GB RAM untuk flow table dan stream reassembly, plus NIC dengan RSS multi-queue (Intel X710, Mellanox ConnectX-5+). Untuk 10 Gbps reliable, target 16+ core fisik dedicated, 64 GB RAM, dan NIC kernel-bypass (AF_XDP atau DPDK).