Security Center：FAQ tentang manajemen kerentanan

Perilaku dan hasil pemindaian

• Mengapa server yang sama melaporkan beberapa instance dari kerentanan yang sama?

  Deteksi kerentanan aplikasi menargetkan instance proses berjalan tertentu. Jika sebuah server menjalankan beberapa instance proses dengan kerentanan yang sama—misalnya, dua layanan Tomcat identik yang dijalankan pada port berbeda—sistem akan melaporkan kerentanan terpisah untuk setiap instance tersebut. Jika perangkat lunak rentan telah diinstal tetapi tidak sedang berjalan, Security Center tidak akan mendeteksi kerentanan tersebut.

• Mengapa hasil pemindaian untuk kerentanan seperti Fastjson kadang-kadang berbeda?

  Deteksi kerentanan semacam ini bergantung pada apakah komponennya (seperti paket JAR) dimuat ke dalam status runtime selama pemindaian. Dalam model pemuatan dinamis, Security Center hanya dapat mendeteksi kerentanan tersebut ketika logika bisnis memanggil komponen yang rentan. Oleh karena itu, hasil pemindaian dapat berbeda pada waktu yang berbeda.

  Catatan

  Untuk meningkatkan akurasi deteksi jenis kerentanan ini, kami merekomendasikan menjalankan pemindaian secara berkala atau beberapa kali.

• Setelah agent offline, mengapa konsol masih menampilkan catatan kerentanan untuk host tersebut?

  Setelah agent offline, Security Center menyimpan catatan kerentanan yang terdeteksi di konsol. Namun, catatan tersebut secara otomatis kedaluwarsa dan Anda tidak dapat melakukan tindakan apa pun terhadapnya, seperti memperbaiki, memverifikasi, atau menghapusnya. Periode kedaluwarsa otomatis untuk kerentanan adalah sebagai berikut:

  Penting

  Security Center hanya akan menghapus semua data secara permanen jika layanan Security Center kedaluwarsa dan tidak diperpanjang dalam waktu 7 hari.

  • Linux Software Vulnerability dan Windows System Vulnerability: Kedaluwarsa setelah 3 hari.

  • Web-CMS Vulnerability: Kedaluwarsa setelah 7 hari.

  • Application Vulnerability: Kedaluwarsa setelah 30 hari.

  • Urgent Vulnerability: Kedaluwarsa setelah 90 hari.

Dampak performa dan keamanan

• Apakah pemindaian kerentanan atau validasi aktif (POC) untuk kerentanan darurat memengaruhi sistem bisnis?

  Umumnya, tidak ada dampak. Validasi aktif (POC) Security Center hanya mengirimkan sejumlah kecil (1–2) permintaan probe yang tidak berbahaya dan tidak melakukan bentuk serangan atau tindakan destruktif apa pun. Dalam kasus langka, risiko minimal mungkin terjadi jika aplikasi target sangat rentan saat menangani input yang tidak terduga.

• Mengapa pemindaian kerentanan terkadang memicu error out-of-memory (OOM)?

  Agent Security Center memiliki batas memori yang dikonfigurasi (200 MB secara default). Jika pemindaian melebihi batas ini, mekanisme OOM sistem akan secara proaktif menghentikan proses deteksi (ALiSecCheck) untuk menghemat sumber daya.

  Catatan

  • Batas ini biasanya dikelola oleh control group (cgroup) bernama aegisRtap0. Informasi OOM terkait dapat ditemukan di log dmesg.

  • Perilaku ini normal dan tidak terkait dengan kekurangan memori di seluruh sistem. Tidak diperlukan intervensi pengguna.

  • Error OOM ini disebabkan oleh batas memori cgroup dan bukan menunjukkan bahwa seluruh sistem kehabisan memori.

Cakupan dan kemampuan pemindaian

1. Apa cakupan pemindaian kerentanan?

   Pemindaian mencakup lapisan sistem dan aplikasi:

   • Tingkat sistem: Linux software vulnerability dan Windows system vulnerability.

     Penting

     Pemindaian kerentanan sistem Windows terbatas pada patch pembaruan keamanan bulanan.

   • Lapisan aplikasi: Web-CMS vulnerability, Application vulnerability, dan Urgent vulnerability.

2. Bagaimana cara melihat daftar kerentanan yang dapat dideteksi oleh Security Center?

   1. Login ke Security Center console.

   2. Di panel navigasi sebelah kiri, klik Vulnerabilities untuk membuka halaman pemindaian kerentanan. Di bagian ikhtisar, temukan kartu statistik Disclosed Vulnerabilities.

   3. Klik jumlah total kerentanan pada kartu tersebut untuk membuka halaman daftar, tempat Anda dapat melihat semua kerentanan yang didukung beserta detailnya.

3. Apakah Security Center mendukung deteksi kerentanan spesifik seperti Elasticsearch?

   Ya. Anda dapat melihat hasil deteksi kerentanan pada layanan seperti Elasticsearch di halaman Application Vulnerability di konsol.

   Catatan

   Fitur ini hanya tersedia untuk layanan Subscription (Enterprise dan Ultimate) serta layanan Pay-as-you-go (Host Protection dan Hosts and Container Protection). Jika edisi Anda saat ini tidak mendukung fitur ini, silakan upgrade terlebih dahulu.

Batasan dan prinsip perbaikan

• Mengapa tombol Fix berwarna abu-abu saat saya mencoba memperbaiki kerentanan?

  • Batasan edisi produk

    • Edisi terlalu rendah: Edisi Basic dan Anti-virus tidak mendukung perbaikan satu klik.

    • Solusi: Beli layanan tambahan "Vulnerability Fixing", atau upgrade ke Edisi Enterprise atau Ultimate.

  • Masalah server

    Linux

    • Sistem operasi tidak lagi didukung: Vendor tidak lagi menyediakan patch. Anda perlu melakukan upgrade versi sistem operasi secara manual. Saat ini, kerentanan pada sistem operasi berikut perlu diperbaiki dengan meng-upgrade OS.

      • Red Hat 5, Red Hat 6, Red Hat 7, Red Hat 8

      • CentOS 5

      • Ubuntu 12

      • Debian 8, 9, 10

    • Disk space tidak mencukupi: Ruang kosong kurang dari 3 GB. Bersihkan atau perluas disk.

    • Proses sedang sibuk: Proses apt atau yum sedang berjalan. Tunggu hingga selesai lalu coba lagi, atau hentikan proses tersebut secara manual.

    • Izin tidak mencukupi: Pengguna yang menjalankan perintah perbaikan tidak memiliki izin yang cukup. Pastikan pemilik file adalah pengguna root dan atur izin yang sesuai, misalnya 755.

    Windows

    • Disk space tidak mencukupi: Ruang kosong kurang dari 500 MB. Bersihkan atau perluas disk.

    • Layanan Windows Update tidak normal: Layanan dinonaktifkan atau sedang berjalan.

      • Dinonaktifkan: Buka pengelola layanan sistem server, aktifkan Windows Update Service, lalu coba perbaiki kerentanan lagi.

      • Sedang berjalan: Jika sedang berjalan, tunggu hingga selesai atau hentikan proses Wusa secara manual di server, lalu coba perbaiki kerentanan lagi.

• Apa perbedaan antara kerentanan aplikasi dan kerentanan sistem? Mengapa perbaikan satu klik tidak mendukung kerentanan aplikasi?

  • Kerentanan sistem, seperti Linux software vulnerabilities dan Windows system vulnerabilities, adalah kerentanan pada sistem operasi atau komponennya. Jalur remediasi mereka distandardisasi, sehingga didukung perbaikan satu klik.

  • Kerentanan aplikasi terdapat pada aplikasi yang di-deploy sendiri, seperti kode website atau perangkat lunak pihak ketiga. Metode remediasinya sangat terkait dengan logika bisnis dan implementasi kode. Kerentanan ini tidak dapat diperbaiki secara otomatis tanpa memahami bisnis, sehingga harus ditangani secara manual.

• Mengapa ada begitu banyak kerentanan di server saya?

  Kerentanan terus ditemukan pada versi perangkat lunak lama karena metode serangan baru selalu muncul. Oleh karena itu, pemindaian dan penerapan patch secara berkala merupakan tugas keamanan yang berkelanjutan. Anda dapat mengaktifkan sakelar Show Only Exploitable Vulnerabilities untuk fokus pada risiko kritis.

Operasi perbaikan

• Apa yang harus saya lakukan jika muncul pesan "Permission acquisition failed, please check permissions and retry" saat menjalankan perintah perbaikan?

  • Penyebab: Pengguna yang memiliki file yang diperlukan untuk operasi perbaikan bukan root, sehingga izin tidak mencukupi.

  • Solusi:

    1. Temukan file tersebut:

       Di Security Center, lihat detail kerentanan untuk mengonfirmasi file spesifik dan jalurnya yang perlu diperbaiki.

    2. Ubah izin:

       Login ke server dan jalankan perintah berikut untuk mengubah pemilik file menjadi root.

    3. Coba perbaiki lagi:

       Kembali ke konsol Security Center dan lakukan operasi perbaikan pada kerentanan tersebut lagi.

• Saat memperbaiki kerentanan secara batch, dalam urutan apa kerentanan tersebut diperbaiki?

  Linux software vulnerabilities dan Web-CMS vulnerabilities diperbaiki secara batch sesuai urutan tampilannya di daftar kerentanan di konsol. Memperbaiki beberapa kerentanan sistem Windows memerlukan pemasangan patch prasyarat terlebih dahulu. Saat memperbaiki kerentanan sistem Windows secara batch, jenis kerentanan ini diperbaiki terlebih dahulu. Kerentanan lainnya diperbaiki sesuai urutan tampilannya di daftar kerentanan di konsol.

• Mengapa restart tidak efektif setelah memperbaiki kerentanan patch kernel Ubuntu?

  • Gejala: Setelah menggunakan perbaikan satu klik di Security Center untuk kerentanan kernel pada server Ubuntu, meskipun muncul pesan "Fixed, pending restart", peringatan kerentanan masih ada setelah server direstart. Sistem belum mengaktifkan kernel yang baru diinstal.

  • Penyebab: Hal ini biasanya karena urutan boot default menu GRUB telah dimodifikasi secara manual sebelumnya. Dalam kasus ini, skrip perbaikan sistem tidak dapat secara otomatis mengatur kernel yang baru diinstal sebagai item boot default.

  • Solusi:

    Solusi 1: Konfigurasi otomatis kernel baru

    Solusi ini mengabaikan konfigurasi GRUB kustom asli dan membiarkan sistem menerapkan pengaturan default secara otomatis untuk kernel baru.

    Prosedur:

    1. Sebelum menjalankan perbaikan kerentanan, login ke server Ubuntu Anda.

    2. Jalankan perintah berikut untuk mengatur variabel lingkungan:

       <BASH>
       
       export DEBIAN_FRONTEND=noninteractive

    3. Kembali ke konsol Security Center dan lakukan perbaikan satu klik pada kerentanan tersebut.

    4. Setelah perbaikan selesai, restart server sesuai petunjuk. Sistem akan secara otomatis mengaktifkan kernel terbaru.

    Solusi 2: Ubah urutan boot secara manual

    Untuk mempertahankan konfigurasi GRUB asli, Anda dapat memilih solusi ini.

    Prosedur:

    1. Di konsol Security Center, lakukan perbaikan satu klik secara normal dan restart server sesuai petunjuk.

    2. Setelah perbaikan dan restart, login ke server Ubuntu Anda.

    3. Ubah urutan boot GRUB secara manual untuk mengatur versi kernel yang baru diinstal sebagai item boot default.

       Catatan

       Operasi spesifik biasanya melibatkan modifikasi file /etc/default/grub dan menjalankan perintah update-grub. Untuk operasi terkait, lihat Modify the kernel boot order for ECS Linux CentOS.

    4. Restart server sekali lagi agar urutan boot baru berlaku.

• Apakah saya perlu merestart sistem setelah memperbaiki kerentanan?

  • Windows: Diperlukan restart.

  • Linux Software Vulnerability: Diperlukan restart jika salah satu kondisi berikut terpenuhi:

    • Kerentanan kernel telah diperbaiki.

    • Di tab Linux Software Vulnerability pada halaman Risk Governance > Vulnerabilities di Security Center console, pengumuman untuk kerentanan tersebut memiliki tag Restart Required.

      

• Mengapa operasi rollback kerentanan gagal?

  Saat operasi rollback kerentanan gagal, Anda dapat melakukan troubleshooting melalui jalur berikut:

  1. Periksa status client (Agent)

     Operasi rollback bergantung pada Agent Security Center yang online. Jika Agent offline, perintah tidak dapat dikirimkan. Anda perlu melakukan troubleshooting dan menyelesaikan masalah offline-nya terlebih dahulu.

  2. Konfirmasi snapshot cadangan masih valid

     Fitur rollback didasarkan pada snapshot cadangan yang dibuat sebelum perbaikan. Jika snapshot telah kedaluwarsa atau dihapus secara manual, rollback tidak dapat dilakukan.

• Mengapa pembuatan snapshot gagal saat memperbaiki kerentanan?

  Pembuatan snapshot saat memperbaiki kerentanan dapat gagal karena alasan berikut:

  • Operasi saat ini dilakukan oleh RAM user: Jika Anda saat ini menggunakan RAM user dan pengguna tersebut tidak memiliki izin untuk membuat snapshot, konsol akan memberi tahu bahwa pembuatan snapshot gagal. Kami merekomendasikan Anda menggunakan Akun Alibaba Cloud untuk operasi ini. Untuk informasi lebih lanjut tentang RAM user, lihat Overview of RAM users.

  • Server bukan server Alibaba Cloud: Server non-Alibaba Cloud tidak mendukung pembuatan snapshot untuk memperbaiki kerentanan.

Status dan verifikasi pasca-perbaikan

• Kerentanan telah diperbaiki, tetapi Security Center masih melaporkannya. Apa yang harus saya lakukan?

  • Penyebab: Hal ini terjadi karena beberapa kerentanan, yaitu kerentanan kernel Linux, memerlukan restart server setelah diperbaiki.

  • Solusi: Di halaman detail kerentanan, klik Restart. Setelah restart selesai, klik Verify. Jika muncul 'Repaired', berarti kerentanan berhasil diperbaiki.

• Host belum menginstal patch yang sesuai. Mengapa menunjukkan bahwa kerentanan Windows berhasil diperbaiki?

  Ini adalah fenomena normal yang disebabkan oleh mekanisme pembaruan Windows. Anda hanya perlu memastikan bahwa pembaruan kumulatif terbaru telah diinstal untuk memperbaiki semua kerentanan historis yang dikandungnya. Anda tidak perlu menginstal patch lama satu per satu.

  Catatan

  Anda dapat mengunjungi situs web resmi patch Microsoft, mencari patch terbaru yang diinstal (biasanya diidentifikasi dengan nomor KB-nya), dan memeriksa "Package Details"-nya untuk mengonfirmasi apakah telah mencakup kerentanan lama yang Anda khawatirkan.

  • Penyebab: Mekanisme pembaruan kumulatif Windows

    Pembaruan keamanan Windows menggunakan model "kumulatif". Artinya, patch keamanan bulanan terbaru adalah paket koleksi yang secara default mencakup semua perbaikan keamanan dari bulan-bulan sebelumnya hingga tanggal rilis.

  • Solusi: Saat Security Center mendeteksi bahwa sistem telah menginstal pembaruan kumulatif terbaru, sistem akan menandai semua kerentanan lama yang dicakupnya sebagai "Fixed". Oleh karena itu, Anda tidak perlu menginstal patch terpisah untuk setiap kerentanan historis.

• Setelah memperbaiki kerentanan, mengapa statusnya masih menunjukkan "Not fixed" di konsol?

  Kemungkinan penyebabnya sebagai berikut:

  1. Verifikasi tertunda: Setelah perbaikan manual, Anda perlu mengklik tombol Verify untuk memicu pemindaian instan. Pembaruan status memerlukan beberapa menit.

  2. Masalah cache: Halaman konsol mungkin memiliki cache. Coba refresh paksa halaman atau tunggu beberapa menit.

  3. Perbaikan tidak lengkap: Operasi perbaikan mungkin tidak sepenuhnya berhasil, atau mungkin ada beberapa jalur kerentanan dan hanya satu yang diperbaiki. Silakan periksa ulang langkah-langkah perbaikannya.

• Fixed and Pending Restarted state vulnerabilities: Apakah Security Center dapat memverifikasinya secara otomatis?

  Tidak. Anda perlu merestart server dari konsol Security Center atau merestart server secara manual. Setelah restart selesai, klik Verify untuk mengonfirmasi apakah kerentanan telah berhasil diperbaiki.

  Penting

  Jika Anda tidak melakukan verifikasi secara aktif, Security Center akan secara otomatis memeriksa selama pemindaian berkala berikutnya. Setelah sistem tidak mendeteksi kerentanan tersebut pada pemindaian pertama, informasi kerentanan akan disimpan selama 3 hari (untuk mencegah kesalahan penilaian akibat jaringan atau alasan lain). Jika tidak terdeteksi selama 3 hari berturut-turut, sistem akan menghapus catatan kerentanan tersebut.

• Mengapa tidak ada respons saat saya melakukan verifikasi manual setelah memperbaiki kerentanan?

  Setelah memperbaiki kerentanan secara manual di server, jika fungsi "Verify" di konsol Security Center tidak dapat memperbarui status kerentanan menjadi "Fixed", biasanya disebabkan oleh dua alasan berikut:

  • Konfigurasi tingkat pemindaian kerentanan tidak lengkap

    • Penyebab: Security Center hanya memindai dan memperbarui level risiko yang dipilih di Vulnerability Settings. Jika level risiko kerentanan target (misalnya, important atau medium) tidak dipilih, sistem tidak akan memperbarui status kerentanan pada level tersebut.

    • Solusi: Verifikasi bahwa level pemindaian di Vulnerability Settings mencakup level risiko kerentanan target.

  • Client (Agent) Security Center offline

    • Penyebab: Fungsi "Verify" bergantung pada komunikasi real-time antara konsol dan client di server. Jika client offline, konsol tidak dapat mengirimkan perintah verifikasi atau menerima hasilnya.

    • Solusi: Lakukan troubleshooting dan selesaikan masalah offline client tersebut. Setelah kembali online, lakukan operasi verifikasi lagi.

Memperbaiki jenis kerentanan tertentu

• Apa yang harus saya lakukan jika Security Center masih melaporkan kerentanan kernel setelah upgrade?

  1. Konfirmasi bahwa kernel telah di-upgrade.

     1. Periksa versi kernel yang sedang berjalan untuk memastikan bahwa versinya memenuhi persyaratan yang ditentukan dalam detail kerentanan.

        uname -av
        cat /proc/version

     2. Konfirmasi bahwa sistem memulai menggunakan kernel baru.

        cat /etc/grub.conf

  2. Periksa dan hapus paket RPM kernel lama.

     1. Lihat semua paket kernel yang diinstal di sistem untuk menemukan paket kernel lama dengan nomor versi lebih rendah dari kernel yang sedang berjalan.

        rpm -qa | grep kernel

     2. Buat snapshot protektif untuk sistem (sangat disarankan).

        Di konsol Elastic Compute Service, buat snapshot atau citra untuk instans saat ini guna mencegah pengecualian sistem atau kegagalan startup yang mungkin disebabkan oleh penghapusan yang tidak disengaja.

     3. Uninstall paket RPM kernel lama.

        2. Hapus hanya versi kernel lama yang tidak digunakan. Misalnya:

           rpm -e kernel-<old_version_number>

        3. Atau, gunakan metode yang direkomendasikan oleh distribusi tersebut. Untuk CentOS/RedHat:

           yum remove kernel-<old_version_number>

  3. Abaikan peringatan

     Jika Anda memastikan bahwa kernel yang sedang berjalan telah memperbaiki kerentanan tersebut, Anda dapat mengabaikan peringatan tersebut.

     1. Login ke Security Center console.

     2. Di panel navigasi sebelah kiri, pilih Risk Governance > Vulnerabilities. Di pojok kiri atas konsol, pilih wilayah tempat aset Anda dideploy: Chinese Mainland atau Outside Chinese Mainland.

     3. Di tab Linux Software Vulnerabilities, temukan kerentanan tersebut dan klik namanya untuk membuka halaman Vulnerability Details.

     4. Di kolom Actions, klik ikon dan pilih Ignore.

• Bagaimana cara memperbarui kernel Ubuntu secara manual?

  Penting

  Memperbarui versi kernel adalah operasi berisiko tinggi. Kami sangat menyarankan Anda mengikuti petunjuk di Suggestions on how to fix server software vulnerabilities untuk memperbarui kernel.

  Contoh berikut menunjukkan cara memperbarui kernel 3.1* ke kernel 4.4 pada sistem Ubuntu 14.04.

  1. Jalankan perintah uname -av untuk mengonfirmasi bahwa versi kernel saat ini adalah 3.1*.

     

  2. Jalankan perintah berikut untuk memeriksa apakah paket pembaruan kernel terbaru tersedia:

     apt list | grep linux-image-4.4.0-94-generic
     apt list | grep linux-image-extra-4.4.0-94-generic

  3. Jika tidak ada pembaruan terkait yang tersedia, Anda dapat menjalankan perintah apt-get update untuk mengambil paket pembaruan terbaru.

  4. Jalankan perintah berikut untuk memperbarui kernel.

     apt-get update && apt-get install linux-image-4.4.0-94-generic
     apt-get update && apt-get install linux-image-extra-4.4.0-94-generic

  5. Setelah paket pembaruan diinstal, restart server untuk menerapkan kernel baru.

  6. Setelah server direstart, jalankan perintah berikut untuk memverifikasi bahwa kernel telah diperbarui:

     • Jalankan perintah uname -av untuk menanyakan kernel yang sedang berjalan.

       

     • Jalankan perintah dpkg -l | grep linux-image untuk menanyakan detail paket kernel saat ini.

       

• Apa yang harus saya lakukan jika beberapa kerentanan di konsol Security Center tidak menampilkan pembaruan?

  Jika kerentanan menunjukkan tidak ada pembaruan yang tersedia, artinya tidak ada sumber pembaruan resmi untuk perangkat lunak yang terpengaruh. Anda tidak dapat memperbaiki kerentanan tersebut di konsol Security Center. Anda dapat memilih solusi berdasarkan petunjuk berikut:

  • Sumber pembaruan resmi belum menyediakan patch

    • Masalah: Saat Anda menjalankan perintah pembaruan, sistem mengembalikan pesan seperti already installed and latest version atau No Packages marked for Update.

    • Paket perangkat lunak yang terpengaruh: Gnutls, Libnl, dan MariaDB

    • Solusi: Tunggu hingga sumber perangkat lunak resmi merilis pembaruan.

  • Versi sistem operasi telah mencapai masa akhir dukungan (EOL)

    • Masalah: Paket perangkat lunak tidak memenuhi persyaratan versi untuk perbaikan kerentanan, meskipun merupakan versi terbaru yang didukung oleh sistem saat ini. Hal ini dapat terjadi pada versi sistem operasi yang tidak lagi didukung secara resmi, seperti CentOS 6.x.

    • Solusi:

      • Solusi 1: Upgrade sistem operasi ke versi yang masih dalam periode dukungan resmi.

      • Solusi 2: Setelah menilai risiko dan memastikan bahwa risiko tersebut dapat dikelola, Anda dapat mengabaikan kerentanan tersebut di konsol Security Center.