Respon insiden dan forensik

Kemampuan Anda untuk bereaksi cepat terhadap suatu insiden dapat membantu meminimalkan kerusakan yang disebabkan oleh pelanggaran. Memiliki sistem peringatan yang andal yang dapat memperingatkan Anda tentang perilaku mencurigakan adalah langkah pertama dalam rencana respons insiden yang baik. Ketika insiden memang muncul, Anda harus segera memutuskan apakah akan menghancurkan dan mengganti wadah yang terkena, atau mengisolasi dan memeriksa wadah. Jika Anda memilih untuk mengisolasi wadah sebagai bagian dari investigasi forensik dan analisis akar penyebab, maka serangkaian kegiatan berikut harus diikuti:

Contoh rencana respons insiden

Mengidentifikasi Pod dan node pekerja yang menyinggung

Tindakan pertama Anda harus mengisolasi kerusakan. Mulailah dengan mengidentifikasi di mana pelanggaran terjadi dan isolasi Pod tersebut dan nodenya dari infrastruktur lainnya.

Mengidentifikasi Pod dan node pekerja yang melanggar menggunakan nama beban kerja

Jika Anda mengetahui nama dan namespace dari pod yang menyinggung, Anda dapat mengidentifikasi node pekerja yang menjalankan pod sebagai berikut:

kubectl get pods <name> --namespace <namespace> -o=jsonpath='{.spec.nodeName}{"\n"}'

Jika Sumber Daya Beb an Kerja seperti Deployment telah dikompromikan, kemungkinan semua pod yang merupakan bagian dari sumber daya beban kerja dikompromikan. Gunakan perintah berikut untuk mencantumkan semua pod Sumber Daya Beban Kerja dan node yang dijalankannya:

selector=$(kubectl get deployments <name> \
 --namespace <namespace> -o json | jq -j \
'.spec.selector.matchLabels | to_entries | .[] | "\(.key)=\(.value)"')

kubectl get pods --namespace <namespace> --selector=$selector \
-o json | jq -r '.items[] | "\(.metadata.name) \(.spec.nodeName)"'

Perintah di atas adalah untuk penerapan. Anda dapat menjalankan perintah yang sama untuk sumber beban kerja lainnya seperti replicasets,, statefulsets, dll.

Mengidentifikasi Pod dan node pekerja yang melanggar menggunakan nama akun layanan

Dalam beberapa kasus, Anda dapat mengidentifikasi bahwa akun layanan dikompromikan. Kemungkinan pod yang menggunakan akun layanan yang diidentifikasi dikompromikan. Anda dapat mengidentifikasi semua pod menggunakan akun layanan dan node yang dijalankannya dengan perintah berikut:

kubectl get pods -o json --namespace <namespace> | \
    jq -r '.items[] |
    select(.spec.serviceAccount == "<service account name>") |
    "\(.metadata.name) \(.spec.nodeName)"'

Mengidentifikasi Pod dengan gambar dan node pekerja yang rentan atau dikompromikan

Dalam beberapa kasus, Anda mungkin menemukan bahwa image kontainer yang digunakan dalam pod di cluster Anda berbahaya atau dikompromikan. Gambar kontainer berbahaya atau dikompromikan, jika ditemukan mengandung malware, adalah gambar buruk yang diketahui atau memiliki CVE yang telah dieksploitasi. Anda harus mempertimbangkan semua pod yang menggunakan gambar wadah yang dikompromikan. Anda dapat mengidentifikasi pod menggunakan gambar dan node yang dijalankannya dengan perintah berikut:

IMAGE=<Name of the malicious/compromised image>

kubectl get pods -o json --all-namespaces | \
    jq -r --arg image "$IMAGE" '.items[] |
    select(.spec.containers[] | .image == $image) |
    "\(.metadata.name) \(.metadata.namespace) \(.spec.nodeName)"'

Isolasi Pod dengan membuat Kebijakan Jaringan yang menolak semua lalu lintas masuk dan keluar ke pod

Aturan tolak semua lalu lintas dapat membantu menghentikan serangan yang sudah berlangsung dengan memutuskan semua koneksi ke pod. Kebijakan Jaringan berikut akan berlaku untuk pod dengan labelapp=web.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
spec:
  podSelector:
    matchLabels:
      app: web
  policyTypes:
  - Ingress
  - Egress

penting

Kebijakan Jaringan mungkin terbukti tidak efektif jika penyerang telah memperoleh akses ke host yang mendasarinya. Jika Anda mencurigai hal itu telah terjadi, Anda dapat menggunakan Grup Keamanan AWS untuk mengisolasi host yang disusupi dari host lain. Saat mengubah grup keamanan host, ketahuilah bahwa itu akan berdampak pada semua kontainer yang berjalan di host tersebut.

Cabut kredentif keamanan sementara yang ditetapkan ke pod atau node pekerja jika perlu

Jika node pekerja telah diberi peran IAM yang memungkinkan Pod mendapatkan akses ke sumber daya AWS lainnya, hapus peran tersebut dari instans untuk mencegah kerusakan lebih lanjut dari serangan. Demikian pula, jika Pod telah ditetapkan peran IAM, evaluasi apakah Anda dapat menghapus kebijakan IAM dengan aman dari peran tersebut tanpa memengaruhi beban kerja lainnya.

Membatasi simpul pekerja

Dengan menutup node pekerja yang terkena dampak, Anda memberi tahu penjadwal untuk menghindari penjadwalan pod ke node yang terpengaruh. Ini akan memungkinkan Anda untuk menghapus node untuk studi forensik tanpa mengganggu beban kerja lainnya.

catatan

Panduan ini tidak berlaku untuk Fargate di mana setiap pod Fargate berjalan di lingkungan kotak pasirnya sendiri. Alih-alih menutup, serap pod Fargate yang terpengaruh dengan menerapkan kebijakan jaringan yang menolak semua lalu lintas masuk dan keluar.

Aktifkan perlindungan penghentian pada node pekerja yang terkena dampak

Penyerang dapat mencoba menghapus kesalahan mereka dengan mengakhiri node yang terpengaruh. Mengaktifkan perlindungan penghentian dapat mencegah hal ini terjadi. Perlindungan skala instans akan melindungi node dari peristiwa scale-in.

Awas

Anda tidak dapat mengaktifkan perlindungan penghentian pada instans Spot.

Label pelanggar Pod/Node dengan label yang menunjukkan bahwa itu adalah bagian dari penyelidikan aktif

Ini akan berfungsi sebagai peringatan kepada administrator cluster untuk tidak merusak yang terpengaruh Pods/Nodes sampai penyelidikan selesai.

Tangkap artefak yang mudah menguap pada node pekerja

• Tangkap memori sistem operasi. Ini akan menangkap daemon Docker (atau runtime container lainnya) dan subprosesnya per container. Ini dapat dicapai dengan menggunakan alat seperti Li ME dan Vol atilitas, atau melalui alat tingkat yang lebih tinggi seperti Automated Forensics Orchestrator untuk Amazon EC2 yang dibangun di atasnya.

• Lakukan dump pohon netstat dari proses yang berjalan dan port terbuka. Ini akan menangkap daemon docker dan subprosesnya per container.

• Jalankan perintah untuk menyimpan status tingkat kontainer sebelum bukti diubah. Anda dapat menggunakan kemampuan runtime container untuk menangkap informasi tentang kontainer yang sedang berjalan. Misalnya, dengan Containerd, Anda dapat melakukan hal berikut:

  • crictl psuntuk proses yang berjalan.

  • crictl logs CONTAINERuntuk log yang disimpan tingkat daemon.

    Hal yang sama dapat dicapai dengan containerd menggunakan nerdctl CLI, sebagai pengganti (mis.). docker nerdctl inspect Beberapa perintah tambahan tersedia tergantung pada runtime container. Misalnya, Docker docker diff harus melihat perubahan pada sistem file container atau docker checkpoint untuk menyimpan semua status wadah termasuk memori volatile (RAM). Lihat posting blog Kubernetes ini untuk diskusi tentang kemampuan serupa dengan containerd atau runtime. CRI-O

• Jeda wadah untuk penangkapan forensik.

• Snapshot volume EBS instans.

Menyebarkan kembali Pod atau Sumber Daya Beban Kerja yang dikompromikan

Setelah mengumpulkan data untuk analisis forensik, Anda dapat menyebarkan kembali pod yang dikompromikan atau sumber daya beban kerja.

Pertama luncurkan perbaikan untuk kerentanan yang dikompromikan dan mulai pod pengganti baru. Kemudian hapus pod yang rentan.

Jika pod rentan dikelola oleh sumber beban kerja Kubernetes tingkat yang lebih tinggi (misalnya, Deployment atau DaemonSet), menghapusnya akan menjadwalkan yang baru. Jadi pod yang rentan akan diluncurkan lagi. Dalam hal ini Anda harus menerapkan sumber daya beban kerja pengganti baru setelah memperbaiki kerentanan. Maka Anda harus menghapus beban kerja yang rentan.

Rekomendasi

Tinjau Dokumen Teknis Tanggapan Insiden Keamanan AWS

Meskipun bagian ini memberikan gambaran singkat bersama dengan beberapa rekomendasi untuk menangani dugaan pelanggaran keamanan, topik ini dibahas secara mendalam dalam buku putih, Tanggapan Insiden Keamanan AWS.

Berlatih hari permainan keamanan

Bagilah praktisi keamanan Anda menjadi 2 tim: merah dan biru. Tim merah akan fokus untuk menyelidiki berbagai sistem untuk kerentanan sementara tim biru akan bertanggung jawab untuk bertahan melawan mereka. Jika Anda tidak memiliki cukup praktisi keamanan untuk membuat tim terpisah, pertimbangkan untuk menyewa entitas luar yang memiliki pengetahuan tentang eksploitasi Kubernetes.

Kubesploit adalah kerangka pengujian penetrasi CyberArk yang dapat Anda gunakan untuk melakukan hari-hari permainan. Tidak seperti alat lain yang memindai cluster Anda untuk mencari kerentanan, kubesploit mensimulasikan serangan dunia nyata. Ini memberi tim biru Anda kesempatan untuk melatih responsnya terhadap serangan dan mengukur efektivitasnya.

Jalankan tes penetrasi terhadap cluster Anda

Menyerang cluster Anda sendiri secara berkala dapat membantu Anda menemukan kerentanan dan kesalahan konfigurasi. Sebelum memulai, ikuti panduan uji penetrasi sebelum melakukan tes terhadap cluster Anda.

Alat dan sumber daya

• kube-hunter, alat pengujian penetrasi untuk Kubernetes.

• Gremlin, toolkit rekayasa kekacauan yang dapat Anda gunakan untuk mensimulasikan serangan terhadap aplikasi dan infrastruktur Anda.

• Menyerang dan Mempertahankan Instalasi Kubernetes

• kubespload

• NeuVector oleh SUSE open source, platform keamanan wadah tanpa kepercayaan, menyediakan pelaporan kerentanan dan risiko serta pemberitahuan peristiwa keamanan

• Ancaman Persisten Tingkat Lanjut

• Serangan dan Pertahanan Praktis Kubernetes

• Mengkompromikan Cluster Kubernetes dengan Mengeksploitasi Izin RBAC