Belajar OpenClaw - DDoS Protection & Rate Limiting

#Pendahuluan

Di episode 12 kalian menutup perimeter dalam: integrasi dengan service mesh, policy lintas batas mesh, serta kendali ingress dan egress. Sekarang bayangkan pintu itu diserbu ribuan request dalam satu detik dari ribuan IP berbeda. Tanpa pertahanan, service down dalam hitungan menit — dan itu bukan lagi pertanyaan "kalau", melainkan "kapan".

Episode 13 adalah materi pertahanan: rate limiting policy dan traffic shaping, pemblokiran traffic mencurigakan dan abuse, serta monitoring threshold dan alerting supaya serangan terdeteksi sebelum sistem jebol.

#Mengapa Cloud Native Rentan terhadap DDoS

DDoS (Distributed Denial of Service) membanjiri service dengan traffic lebih besar dari kapasitasnya. Di cloud native ancamannya dua lapis. Pertama, volume attack di layer 3/4 — SYN flood, UDP flood — menguras CPU proxy dan bandwidth. Kedua, dan lebih jahat, application layer attack di layer 7: HTTP flood yang berpura-pura jadi request normal, memaksa aplikasi mengeksekusi query database atau memproses body besar berulang-ulang.

Yang membuat cloud native rentan adalah autoscaling yang salah arah. Saat traffic membanjir, HorizontalPodAutoscaler justru menambah replica — dan tagihan melonjak sementara request itu sendiri tidak pernah berniat membeli apa pun. Rate limiting hadir untuk menghentikan ini di gerbang, bukan membiarkan serangan mengendalikan biaya.

#Rate Limiting Policy dan Traffic Shaping

Rate limiting di OpenClaw bekerja di data plane, sebelum request masuk ke aplikasi. Ada dua strategi klasik: token bucket, yang mengizinkan ledakan singkat (burst) sampai batas tertentu, dan fixed window, yang menghitung request per rentang waktu tetap. OpenClaw memakai keduanya tergantung kebutuhan, dan dinyatakan sebagai policy biasa:

rate-limit.yaml

apiVersion: openclaw.io/v1
kind: RateLimitPolicy
metadata:
  name: api-per-client
  namespace: openclaw-system
spec:
  scope: ingress
  target:
    serviceLabels:
      app: api-gateway
  limit:
    requestsPerMinute: 300
    burst: 50
  keyBy:
    - clientIp
    - apiKey
  overLimitAction: reject

Policy ini membatasi 300 request per menit per kombinasi clientIp dan apiKey, dengan izin ledakan 50 request. Request yang lewat batas langsung ditolak dengan 429 Too Many Requests. Sebelum di-apply, setiap policy diuji dulu dengan openclaw policy validate untuk memastikan strukturnya benar. Setelah lolos, terapkan:

Apply dan cek policy

openclaw policy validate --file rate-limit.yaml
kubectl apply -f rate-limit.yaml

Traffic shaping melangkah lebih halus dari sekedar menolak. Alih-alih memutus koneksi, OpenClaw bisa menunda, menyusutkan burst, atau menurunkan prioritas pelanggan yang boros. Ini menjaga pengguna normal tetap nyaman sambil tetap menahan penyalahgunaan:

traffic-shaping.yaml

apiVersion: openclaw.io/v1
kind: TrafficPolicy
metadata:
  name: shape-bursty-clients
  namespace: openclaw-system
spec:
  target:
    serviceLabels:
      app: web-store
  shaping:
    maxConcurrentRequests: 200
    burstDelayMs: 150
    prioritizeLabels:
      - subscription: premium
    deprioritizeLabels:
      - subscription: free

Warning

Rate limit yang terlalu ketat bisa memblokir pengguna sah — yang namanya thundering herd, semua user mengirim request bersamaan tepat setelah iklan. Naikkan threshold bertahap sambil memantau error rate 429, dan pastikan ada mekanisme retry eksponensial di sisi client.

#Memblokir Traffic Mencurigakan dan Abuse

Rate limiting menghentikan volume, tapi belum mengenali siapa musuhnya. OpenClaw punya lapisan deteksi: IP yang melanggar threshold beberapa kali masuk daftar reputasi buruk, lalu di-block otomatis. Aturan block bisa mengombinasikan banyak sinyal — IP, geolokasi, pola User-Agent, hingga kecepatan request per detik:

blocklist-policy.yaml

apiVersion: openclaw.io/v1
kind: BlockPolicy
metadata:
  name: auto-block-abusers
  namespace: openclaw-system
spec:
  detection:
    ipReputation: enabled
    geoblock:
      mode: allowlist
      regions: [ID, SG, US]
    userAgentRules:
      - pattern: "^curl/"
        action: block
    anomaly:
      requestsPerSecondThreshold: 50
  response:
    blockDuration: 15m
    httpStatus: 403

Selama durasi blok, semua request dari IP itu ditolak dengan 403 tanpa dikirim ke aplikasi — murah, cepat, dan tidak menghabiskan resource. Sinyal yang memicu blok juga direkam, sehingga saat kalian mengecek kenapa IP tertentu di-block, jawabannya bisa dipertanggungjawabkan:

Lihat riwayat pemblokiran

openclaw blocklist list
openclaw blocklist describe 203.0.113.42

Hati-hati dengan false positive: geoblock yang terlalu agresif bisa memutus pengguna sah di luar region, dan blok berbasis User-Agent bisa menangkap bot sah seperti crawler Google. Selalu mulai dari mode report (catat, jangan block) selama beberapa hari sebelum mengaktifkan aksi block penuh.

#Monitoring Threshold dan Alerting

Pertahanan terbaik adalah yang terlihat. Setiap keputusan rate limit dan blok menghasilkan metrik yang bisa dibaca Prometheus: jumlah request, jumlah yang ditolak karena rate limit, IP yang di-block, dan latensi evaluasi. Dari metrik ini kita susun threshold dan alert:

prometheus-alert.yaml

groups:
  - name: openclaw-ratelimit.rules
    rules:
      - alert: HighRejectionRate
        expr: |
          sum(rate(openclaw_requests_rejected_total[5m]))
            / sum(rate(openclaw_requests_total[5m])) > 0.2
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Rejection rate melebihi 20 persen"
      - alert: DDoSVolumeSpike
        expr: |
          sum(rate(openclaw_requests_total[1m]))
            > 10 * (sum(rate(openclaw_requests_total[5m])) + 1)
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Volume request melonjak sepuluh kali lipat"

Dua aturan ini menangkap dua skenario: HighRejectionRate memberi tahu bahwa banyak request ditolak (mungkin rate limit keliru atau memang diserang), sedangkan DDoSVolumeSpike mendeteksi lonjakan volume mendadak yang khas serangan. Alert dikirim ke Alertmanager dan diteruskan ke Slack atau PagerDuty:

Cek metrik dan alert

openclaw metrics rate-limit --interval 5m
promtool check rules prometheus-alert.yaml

Kunci alerting yang efektif adalah baseline. Selidiki volume normal per jam, lalu pasang alert di kelipatan baseline itu — bukan angka absolut yang disetel sekali lalu dilupakan. Threshold yang terlalu rendah membanjiri on-call; yang terlalu tinggi membuat serangan sudah lewat sebelum alert berbunyi.

#Penutup

Episode 13 melengkapi OpenClaw dengan lapisan pertahanan volume: rate limiting dan traffic shaping menahan banjir di gerbang, blocklist dan deteksi anomali memblokir pelaku yang sudah dikenal, dan monitoring threshold plus alerting membuat serangan terlihat sedini mungkin. Beban aplikasi tetap jinak bahkan saat dunia luar mengamuk.

Inti yang harus dibawa pulang:

Bedakan volume attack di layer 3/4 dengan application layer attack di layer 7; keduanya butuh penanganan berbeda.
Gunakan token bucket untuk mengizinkan burst, dan shaping untuk menunda daripada memutus pengguna boros.
Aktifkan blok otomatis berbasis reputasi IP dan anomali, tapi mulai dari mode report untuk menekan false positive.
Ukur rejection rate dan volume spike sebagai metrik utama pertahanan, bukan sekadar jumlah request.
Kalibrasi alert terhadap baseline traffic normal, bukan angka tebakan.

Serangan sudah bisa ditahan, tapi bagaimana cara membuktikan apa yang terjadi saat insiden? Di episode 14 kita masuk ranah investigasi: Network Observability & Forensics — visibilitas aliran paket, audit log, dan penggabungan metrics, traces, dan logs untuk merekonstruksi insiden. Sampai jumpa di sana!