Anatomi I/O Starvation Akibat Live Memory Dump Saat Flash Traffic Menyerang Node Kubernetes

Pukul dua dini hari saat kampanye belanja kuartalan sedang berada di puncaknya, sistem Security Information and Event Management (SIEM) mendeteksi anomali pada salah satu worker node Kubernetes: pola syscall tak lazim yang mengindikasikan potensi container escape. Sesuai runbook standar preservasi bukti digital—sebagaimana sering ditekankan dalam tren investigasi insiden modern seperti yang diulas oleh Tim DFIR KRES—tim keamanan langsung mengeksekusi skrip otomatisasi untuk mengamankan volatile memory dan root disk image sebelum penyerang menghapus jejaknya. Niatnya melindungi integritas bukti forensik, namun hitungan detik kemudian pager tim infrastruktur meledak. Latensi p99 API gateway melonjak dari 15 milidetik ke 8.500 milidetik. Node tersebut gagal merespons readiness probe, kubelet mengalami heartbeat timeout, dan orkestrator mulai mengeksekusi pod eviction massal yang mengirimkan gelombang kejut thundering herd ke sisa kluster yang sudah kepayahan. Upaya menyelamatkan data forensik justru memicu outage produksi secara mandiri.

Anatomi Kerusakan di Lapisan Kernel: Page Cache dan Dirty Writeback

Ketika proses investigasi membaca /proc/kcore atau memanfaatkan modul kernel seperti LiME (Linux Memory Extractor) untuk menyalin 32 GB hingga 64 GB RAM fisik ke local filesystem atau network share, sistem operasi memperlakukan operasi baca-tulis tersebut layaknya I/O file reguler. Di sinilah malapetaka kernel dimulai. Secara default, Linux menggunakan memori bebas sebagai page cache guna mempercepat operasi file I/O pod aplikasi. Ketika proses dump memori berjalan secara masif, kernel membanjiri page cache dengan transient data yang hanya dibaca sekali. Proses ini mengusir (evict) halaman-halaman cache penting milik worker aplikasi—seperti binary program yang sedang dieksekusi, dynamic libraries, dan pool mmap database lokal. Akibatnya, aplikasi produksi yang tadinya melayani puluhan ribu transaksi per detik mendadak mengalami major page faults beruntun. Situasi memburuk ketika kernel memasuki kondisi dirty memory throttling. Saat rasio data kotor (dirty pages) di memori melampaui ambang batas vm.dirty_ratio atau vm.dirty_background_ratio, kernel akan mengaktifkan mekanisme proteksi internal: fungsi balance_dirty_pages(). Mekanisme ini secara agresif memaksa thread apa pun yang mencoba melakukan operasi write—termasuk worker thread aplikasi yang sedang menulis log transaksi atau respons API—untuk tidur (sleep) sementara kernel melalukan flush data ke disk melalui kworker.

Hancurnya Kuota IOPS dan Meluasnya Kubelet Pains

Di lingkungan cloud modern seperti AWS, sebagian besar instance Kubernetes menggunakan volume Amazon EBS tipe gp3 atau gp2. Volume ini memiliki konfigurasi baseline (misalnya 3.000 IOPS dengan throughput 125 MB/s). Operasi pembuatan disk image langsung menggunakan perintah sederhana semacam dd atau cat ke disk lokal akan langsung melahap seluruh jatah burst bucket dan bandwidth I/O instance dalam hitungan detik. Ketika volume storage mencapai saturasi 100% utilitas, queue depth menumpuk drastis dan latensi storage meroket dari rata-rata di bawah 1 milidetik menjadi ribuan milidetik. Korbannya bukan hanya aplikasi bisnis, melainkan komponen inti node itu sendiri:

kubelet Sync Loop Hang: Daemon kubelet secara periodik melakukan operasi baca-tulis ke direktori /var/lib/kubelet dan /var/log/pods. Ketika I/O macet, loop rekonsiliasi container terblokir (berstatus uninterruptible sleep atau D state).
Plesetan NodeStatus: Kubelet gagal mengirimkan pembaruan status sewa (node lease) ke API server. Kubernetes control plane lantas menyimpulkan bahwa node tersebut mati (NodeNotReady), lalu memulai terminasi pod secara brutal di node tersebut dan memindahkannya ke node lain yang berujung cascading failure.

BASH

# Periksa apakah proses aplikasi Anda terjebak dalam I/O wait (D state)
ps -eo pid,user,state,wchan:20,comm | awk '3 ~ /D/ { print0 }'

# Pantau lonjakan dirty pages dan throttling balance_dirty_pages
grep -E 'nr_dirty|nr_writeback|nr_dirtied' /proc/vmstat

Membedah Insiden Tanpa Mengorbankan Node Produksi

Preservasi artefak digital tidak boleh mengancam kelangsungan hidup (resilience) infrastruktur produksi. Untuk menghindari I/O starvation dan cache pollution, kita harus mendesain arsitektur pengumpulan data yang beroperasi di luar jalur kritis (out-of-band). Langkah pertama adalah beralih dari in-guest snapshotting ke hypervisor-level storage snapshot. Daripada menjalankan perkakas forensik di dalam container atau node OS untuk mengkloning partisi disk, manfaatkan Container Storage Interface (CSI) VolumeSnapshot atau langsung panggil API cloud provider (seperti EBS Snapshots). Fitur ini bekerja menggunakan primitives Copy-on-Write (CoW) pada lapisan block storage di luar CPU dan bandwidth I/O instance, sehingga biaya I/O pada instance produksi praktis nol. Langkah kedua berkaitan dengan penanganan volatile memory. Jika live memory capture benar-benar diwajibkan oleh protokol keamanan, eksekusi ekstraksi harus diisolasi ketat menggunakan cgroups v2 dan teknik direct I/O. Jangan biarkan agent keamanan berjalan di bawah slice default system.slice tanpa batasan.

INI

# Contoh systemd drop-in override untuk agent forensik (misal: /etc/systemd/system/dfir-agent.service.d/override.conf)
[Service]
MemoryHigh=1G
MemoryMax=1.5G
IOWeight=20
IOReadIOPSMax=/dev/nvme0n1 250
IOWriteIOPSMax=/dev/nvme0n1 150

Konfigurasi cgroups di atas memastikan daemon triage hanya mendapatkan alokasi I/O minimal (IOWeight=20) dibandingkan worker pod aplikasi, serta membatasi IOPS puncak agar tidak memicu kehabisan kuota disk instance. Selain itu, tool ekstraksi memori harus dikonfigurasi agar memotong kernel page cache sepenuhnya dengan memanfaatkan flag O_DIRECT saat menulis file artefak, atau memanggil posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED) segera setelah blok data dikirim ke tujuan streaming jaringan via socket TLS terisolasi. Menjaga integritas forensik di era infrastruktur kontainer terdistribusi bukan lagi sekadar mengikuti checklist konvensional seperti yang umum diajarkan di kelas keamanan siber statis. Respons keamanan yang matang harus memahami mekanika kernel Linux secara mendalam: bagaimana virtual memory, block layer, dan orkestrator saling bertabrakan ketika sistem dipaksa beroperasi di titik ekstrem beban produksi.