Belajar Site Reliability Engineer - DDoS & Traffic Protection

#Pendahuluan

Semua kemampuan SRE kalian mengasumsikan satu hal: pengguna datang dengan niat baik. Tetapi terkadang pengguna tidak datang — sesuatu yang lain datang, dengan volume yang dirancang untuk membuat service kalian menyerah. DDoS (Distributed Denial of Service) mengubah lawan dari kegagalan acak menjadi serangan terorganisir, dan alasan kenapa ini masuk urusan SRE sederhana: targetnya bukan data, melainkan availability — metrik yang selama ini kalian jaga dengan SLO.

Yang perlu dipahami sejak awal: serangan DDoS tidak selalu bisa dimenangkan sendirian, dan menang tidak selalu berarti menolak semuanya. Episode 20 membahas pola serangan, rate limiting yang benar, peran WAF, dan strategi bertahan yang berlapis.

#Memahami Pola Serangan

DDoS bukan satu hal, melainkan spektrum dengan tiga lapisan serangan yang berbeda — dan lapisan yang diserang menentukan strategi yang relevan:

Pola L7 adalah yang paling berbahaya bagi SRE karena ia terlihat seperti trafik normal: request sah tapi berlebihan. Di situlah rate limiting dan proteksi aplikasi bekerja — sementara serangan volume besar (L3/L4) biasanya membutuhkan penyedia dengan kapasitas jaringan raksasa (CDN/cloud scrubbing).

#Rate Limiting: Proteksi yang Adil

Rate limiting adalah aturan: berapa banyak request yang boleh masuk per identitas per satuan waktu. Ini melindungi layanan dari overload sekaligus memberi batas yang jelas bagi klien yang baik.

#Algoritma yang Umum

• Fixed window: batas per interval tetap — sederhana, tapi bocor di perbatasan interval.
• Sliding window / token bucket: batas bergeser halus — lebih adil, sedikit lebih kompleks.
• Adaptive: batas menyesuaikan kesehatan sistem (bisa mengecil saat beban tinggi).

#Kunci Implementasi

Identitas pembatas harus dipilih dengan hati-hati. Rate limit per IP memblokir pengguna yang berbagi satu IP korporat; rate limit per API key / user lebih adil, tapi bisa disalahgunakan penyerang yang membuat banyak akun. Kombinasi keduanya adalah praktik umum.

rate_limits:
  - identity: user_id        # adil untuk pengguna nyata
    limit: 120
    per: 60s
    response: 429 + Retry-After
  - identity: ip             # jaring pengaman saat akun dibajak
    limit: 3000
    per: 60s
    response: 429

#WAF: Menyaring Serangan di Gerbang

Web Application Firewall (WAF) berdiri di depan aplikasi dan menyaring request berdasarkan pola serangan yang dikenal: SQL injection, XSS, path traversal, dan manipulasi lainnya. WAF adalah teman, bukan pengganti, dari keamanan aplikasi (episode 19) — ia menangkap yang sudah dikenal di gerbang, sementara aplikasi melindungi dirinya dari yang baru.

Yang perlu dipahami SRE tentang WAF:

• Managed ruleset (misal OWASP CRS) memberi proteksi dasar seketika, dengan risiko false positive yang harus diukur terhadap trafik nyata.
• Custom rules untuk karakteristik bisnis kalian — misal memblokir pola URL aneh yang hanya dipakai bot.
• WAF menambahkan latensi dan single point of failure baru — jangan lupa ukur dampaknya pada SLO (episode 15 & 18).
• Aturan WAF di-deploy sebagai kode (episode 14) — bukan diklik di dashboard.

{
  "name": "block-known-bot-login",
  "priority": 1,
  "statement": {
    "notStatement": {
      "statement": {
        "byteMatchStatement": {
          "fieldToMatch": { "header": { "name": "user-agent" } },
          "searchString": "Mozilla",
          "positionalConstraint": "CONTAINS"
        }
      }
    },
    "fieldToMatch": { "uriPath": { "path": "/login" } }
  },
  "action": "BLOCK"
}

#Menahan Traffic Spike: Strategi Berlapis

Strategi pertahanan yang sehat tidak bergantung pada satu lapisan — ia berlapis dan tiap lapisan punya tugas:

1. Edge / CDN: menyerap volume raksasa dan memblokir serangan L3/L4 di titik dengan kapasitas paling besar.
2. WAF + rate limiting: menyaring dan membatasi di gerbang aplikasi.
3. Caching: melayani request berulang tanpa menyentuh backend — mengurangi beban 10-100x untuk konten yang bisa di-cache.
4. Autoscaling (episode 8 & 10): menambah kapasitas sebagai penyangga terakhir — bukan pertahanan utama, karena scaling tanpa batas adalah bom biaya.
5. Circuit breaker (episode 21): ketika semua gagal, hancurkan diri sendiri secara terhormat — fail fast, lindungi dependency.

Prinsip kuncinya: semakin dekat ke pengguna, semakin murah untuk menahan. Menolak serangan di CDN biayanya nyaris nol; menahan serangan di server aplikasi biayanya CPU, koneksi, dan stres.

#Praktik: Proteksi Endpoint Kritis

Terapkan pada endpoint /login dan /checkout di lab kalian:

1. Pasang rate limit per user (misal 20 request/menit untuk login) dengan 429 + Retry-After.
2. Tambahkan WAF atau minimal aturan blocklist di depan layanan — jika tidak punya WAF, gunakan middleware rate limiter di aplikasi.
3. Cache statis di CDN/edge sehingga serangan ke path statis tidak menyentuh backend.
4. Siapkan mode emergency: tombol untuk menurunkan batas rate limit secara global saat serangan terdeteksi (satu perubahan di config, bukan edit banyak service).
5. Uji: jalankan traffic spike (episode 15, k6 dengan VU tinggi) dan verifikasi bahwa service tetap melayani pengguna yang sah di bawah batas.

#Penutup

Pada episode 20 ini, kalian telah belajar menahan trafik yang berubah menjadi senjata.

Inti yang harus dibawa pulang:

• DDoS menyerang tiga lapisan berbeda; strategi bertahan harus berlapis.
• Rate limiting dengan identitas yang tepat dan header Retry-After yang benar.
• WAF menyaring pola serangan di gerbang, di-deploy sebagai kode.
• Serangan paling murah ditahan paling dekat dengan pengguna: CDN → WAF → rate limit → cache → scaling → breaker.
• Sukses diukur dari pengguna sah yang tetap terlayani, bukan semua request yang ditolak.

Di episode 21 selanjutnya, kita masuk ke jantung sistem modern: distributed systems reliability — konsistensi, partitioning, retry/backoff, circuit breaker, dan idempotency dalam kode. Sampai jumpa di episode 21!