Security Center:FAQ tentang manajemen kerentanan

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

Security Center mendeteksi kerentanan aplikasi berdasarkan instance proses yang sedang berjalan. Jika sebuah server menjalankan dua instance proses yang sama dengan kerentanan yang sama (misalnya, dua layanan Tomcat pada port berbeda), masing-masing dilaporkan secara terpisah. Perangkat lunak yang diinstal tetapi tidak berjalan tidak dipindai.

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

Security Center hanya mendeteksi kerentanan ketika logika bisnis memanggil komponen rentan (seperti paket JAR) saat runtime. Dalam model pemuatan dinamis, hasilnya bervariasi tergantung pada komponen mana yang aktif selama setiap pemindaian.

Setelah agen offline, mengapa konsol masih menampilkan catatan kerentanan?

Security Center menyimpan catatan kerentanan setelah agen offline, tetapi catatan tersebut menjadi kedaluwarsa dan tidak dapat diperbaiki, diverifikasi, atau dihapus. Masa kedaluwarsa:

Apakah pemindaian kerentanan atau validasi proof of concept (POC) untuk kerentanan mendesak memengaruhi sistem bisnis?

Umumnya tidak. Validasi POC hanya mengirimkan 1–2 permintaan probe yang tidak berbahaya tanpa tindakan serangan atau destruktif apa pun. Risiko minimal hanya ada jika aplikasi target sangat rapuh saat menangani input yang tidak terduga.

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

Agen memiliki batas memori 200 MB. Jika pemindaian melebihi batas ini, mekanisme OOM akan menghentikan proses deteksi (ALiSecCheck).

Ini merupakan hal normal dan tidak terkait dengan kekurangan memori sistem secara keseluruhan. Batas ini dikelola oleh cgroup aegisRtap0. Entri OOM muncul dalam log dmesg. Tidak diperlukan tindakan apa pun.

Apa cakupan pemindaian kerentanan?

Pemindaian mencakup lapisan sistem dan aplikasi:

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

1. Login ke Konsol Security Center.

2. Di panel navigasi sebelah kiri, pilih Risk Governance > Vulnerabilities.

3. Di bagian ikhtisar, temukan kartu statistik Disclosed Vulnerabilities dan klik jumlah totalnya untuk melihat semua kerentanan yang dapat dideteksi beserta detailnya.

Apakah Security Center mendukung deteksi kerentanan pada layanan seperti Elasticsearch?

Ya. Lihat hasil deteksi di halaman Application Vulnerability di konsol.

Apakah Security Center memberikan peringatan untuk kerentanan CVE yang belum termasuk dalam basis data kerentanan?

Security Center hanya memberikan peringatan untuk kerentanan yang sudah diketahui dan termasuk dalam basis data kerentanan. Jika CVE belum diumumkan secara resmi atau belum dimasukkan, sistem tidak dapat mengidentifikasi risiko tersebut dan tidak mengirimkan peringatan. Jika kerentanan telah diumumkan dengan patch yang tersedia tetapi masih belum terdeteksi, verifikasi apakah mitigasi atau perbaikan manual telah diterapkan. Kami merekomendasikan mengikuti advis keamanan Alibaba Cloud. Setelah kerentanan diumumkan secara resmi dan vendor merilis patch, Security Center akan memperbarui aturan deteksinya.

Di mana saya dapat menemukan klasifikasi aturan kerentanan terbaru setelah penyesuaian aturan?

Beberapa aturan kerentanan mungkin dihapus dari kategori kerentanan aplikasi karena false positive dan diklasifikasikan ulang sebagai kerentanan sistem. Anda dapat memeriksa klasifikasi terbaru di daftar Supported vulnerabilities pada halaman Vulnerabilities.

Apakah Security Center mendukung Ubuntu 24.04? Bagaimana cara memindai kerentanan secara manual?

Security Center mendukung pemindaian kerentanan secara manual. Distribusi Linux utama umumnya didukung. Untuk memindai, login ke konsol, buka Risk Governance > Vulnerabilities, pilih wilayah di pojok kiri atas, klik Scan Now, dan pilih jenis kerentanan. Atau, di halaman Host, pilih server target dan gunakan opsi pemindaian kerentanan di bawah Security Check. Untuk dukungan versi OS tertentu, rujuk hasil pemindaian aktual di konsol.

Mengapa hasil deteksi Security Center dan perangkat lunak keamanan pihak ketiga (seperti Huorong) berbeda?

Security Center terutama mendeteksi patch resmi sistem Windows (seperti pembaruan kumulatif KBxxxxx), sedangkan perangkat lunak keamanan pihak ketiga seperti Huorong mungkin tidak mencakup patch tingkat sistem ini atau menggunakan strategi deteksi yang berbeda. Perbedaan hasil merupakan hal yang normal.

Mengapa instance yang tidak aktif masih menampilkan peringatan kerentanan berisiko tinggi?

Kemungkinan penyebabnya meliputi:

• Aset lama (instance atau snapshot yang belum sepenuhnya dilepas).

• Risiko sumber daya terkait (seperti kelemahan konfigurasi pada OSS, RDS, atau produk cloud lainnya).

• Keterlambatan sinkronisasi data.

Jika status peringatan menunjukkan Passed, tidak ada risiko aktif dan dapat diabaikan.

Mengapa kerentanan historis muncul dan skor keamanan berubah setelah menonaktifkan toggle "Show only real-risk vulnerabilities"?

Kerentanan aplikasi mungkin telah dipindai sebelumnya tetapi tidak ditampilkan karena toggle tersebut diaktifkan. Setelah toggle dinonaktifkan, kerentanan historis ditampilkan, sehingga skor keamanan diperbarui. Skor tersebut akan diperbarui lagi setelah periode tertentu.

Apakah pemindaian baru menggunakan atau memulihkan data kerentanan historis?

Tidak. Security Center hanya menyimpan data kerentanan yang masih berlaku (kerentanan yang terdeteksi dalam 30 hari terakhir). Setiap pemindaian merupakan deteksi independen berdasarkan status aset saat ini. Catatan kerentanan historis yang kedaluwarsa dan telah dihapus tidak dimuat ulang.

Bagaimana cara membedakan antara pemindaian aktif dan deteksi pasif dalam hasil pemindaian kerentanan Security Center?

Dalam hasil pemindaian, entri yang ditandai sebagai Web Scanner berasal dari pemindaian aktif (mengirim permintaan probe melalui IP publik untuk verifikasi) dan harus diprioritaskan untuk perbaikan. Entri yang ditandai sebagai Software Composition Analysis berasal dari deteksi pasif (membandingkan informasi versi perangkat lunak yang dikumpulkan secara lokal melalui Agen).

Mengapa hasil deteksi kerentanan aplikasi tidak menampilkan path file spesifik?

Deteksi kerentanan aplikasi menargetkan instance proses yang sedang berjalan. Jika kerentanan terdeteksi tetapi tidak menampilkan path file spesifik, rujuk saran dalam detail kerentanan atau periksa path umum (seperti file JAR di direktori kerja Tomcat). Untuk kerentanan kompleks (seperti deserialisasi Jackson), Anda mungkin perlu login ke server dan memeriksa path potensial yang disediakan (seperti /data/.../jackson-databind-*.jar).

Apakah hasil pemindaian kerentanan Security Center menimpa data historis?

Ya. Setelah pemindaian selesai, hasilnya diperbarui secara otomatis (ditimpa) di halaman detail aset di konsol. Anda dapat melihat hasil terbaru dengan membuka Risk Governance > Vulnerabilities, atau klik Task Management di pojok kanan atas untuk melihat status eksekusi tugas pemindaian.

Mengapa tombol Fix berwarna abu-abu?

Paling umum, edisi Anda tidak mendukung perbaikan satu klik. Edisi Dasar dan Edisi Anti-virus tidak memiliki fitur ini. Beli layanan tambahan Vulnerability Fixing, atau tingkatkan ke Edisi Perusahaan atau Edisi Ultimate.

Jika edisi Anda mendukung perbaikan satu klik, periksa masalah di sisi server:

Linux

Windows

Mengapa kerentanan aplikasi tidak dapat diperbaiki dengan perbaikan satu klik?

Kerentanan sistem (kerentanan perangkat lunak Linux dan kerentanan sistem Windows) berada di komponen OS dengan jalur remediasi standar, sehingga memungkinkan perbaikan satu klik.

Kerentanan aplikasi berada di kode yang di-deploy sendiri atau perangkat lunak pihak ketiga. Remediasi bergantung pada logika bisnis Anda, sehingga harus diperbaiki secara manual.

Mengapa ada begitu banyak kerentanan di server saya?

Perangkat lunak lama mengumpulkan kerentanan seiring munculnya metode serangan baru. Untuk fokus pada risiko prioritas tertinggi, aktifkan toggle Show Only Exploitable Vulnerabilities.

Apa yang harus saya lakukan jika mendapatkan error "Permission acquisition failed" saat memperbaiki kerentanan?

File yang diperlukan untuk perbaikan tidak dimiliki oleh root.

1. Di Security Center, lihat detail kerentanan untuk mengidentifikasi file spesifik dan path-nya.

2. Login ke server dan ubah pemilik file menjadi root.

3. Kembali ke Konsol Security Center dan coba lagi perbaikannya.

Dalam urutan apa kerentanan diperbaiki dalam batch?

Kerentanan perangkat lunak Linux dan kerentanan Web-CMS diperbaiki sesuai urutan tampilannya di daftar konsol.

Kerentanan sistem Windows yang memerlukan patch prasyarat diperbaiki terlebih dahulu. Kerentanan lainnya kemudian diperbaiki sesuai urutan tampilannya di daftar konsol.

Mengapa restart tidak efektif setelah memperbaiki kerentanan kernel Ubuntu?

Hal ini terjadi ketika urutan boot GRUB dimodifikasi secara manual sebelum perbaikan. Skrip perbaikan sistem tidak dapat secara otomatis mengatur kernel yang baru diinstal sebagai item boot default.

Solusi 1: Mengonfigurasi kernel baru secara otomatis

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

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

2. Jalankan perintah berikut:

      export DEBIAN_FRONTEND=noninteractive

3. Kembali ke Konsol Security Center dan jalankan perbaikan satu klik.

4. Restart server seperti yang diminta. Sistem secara otomatis mengaktifkan kernel terbaru.

Solusi 2: Memodifikasi urutan boot secara manual

Gunakan solusi ini untuk mempertahankan konfigurasi GRUB asli.

1. Di Konsol Security Center, jalankan perbaikan satu klik dan restart server seperti yang diminta.

2. Login ke server Ubuntu Anda.

3. Modifikasi urutan boot GRUB untuk mengatur kernel yang baru diinstal sebagai item boot default. Ini biasanya melibatkan modifikasi /etc/default/grub dan menjalankan update-grub. Lihat Modify the kernel boot order for ECS Linux CentOS.

4. Restart server lagi.

Apakah saya perlu me-restart sistem setelah memperbaiki kerentanan?

• Windows: Restart selalu diperlukan.

• Linux Software Vulnerability: Restart diperlukan jika kerentanan kernel telah diperbaiki, atau jika kerentanan memiliki tag Restart Required di tab Linux Software Vulnerability di bawah Risk Governance > Vulnerabilities di Konsol Security Center.

Perbaikan otomatis biasanya tidak menyebabkan server mati, tetapi beberapa perbaikan kerentanan kernel mungkin memerlukan restart. Kami merekomendasikan melakukan operasi ini pada jam sepi dan membuat snapshot sebelum perbaikan.

Mengapa rollback kerentanan gagal?

Dua penyebab umum:

• Agen offline: Operasi rollback bergantung pada agen Security Center yang online. Jika agen offline, perintah tidak dapat dikirimkan. Pecahkan dan atasi terlebih dahulu masalah konektivitas agen.

• Snapshot cadangan tidak valid: Rollback bergantung pada snapshot cadangan yang dibuat sebelum perbaikan. Jika snapshot telah kedaluwarsa atau dihapus secara manual, rollback tidak dapat dilanjutkan.

Mengapa pembuatan snapshot gagal saat memperbaiki kerentanan?

• Pengguna RAM tanpa izin: Pengguna RAM tidak memiliki izin pembuatan snapshot. Gunakan Akun Alibaba Cloud untuk operasi ini. Overview of RAM users.

• Server non-Alibaba Cloud: Pembuatan snapshot untuk perbaikan kerentanan hanya didukung pada server Alibaba Cloud.

Apakah Security Center mendukung pemindaian dan perbaikan kerentanan untuk sistem operasi yang telah mencapai end-of-life (EOL)?

Untuk versi OS yang telah mencapai end-of-life (seperti CentOS 7.6), Security Center tidak mendukung pemindaian kerentanan atau perbaikan satu klik. Jika tidak ada kerentanan yang terdeteksi, verifikasi apakah versi OS Anda berada dalam rentang yang didukung. Jika tidak, kami merekomendasikan untuk meningkatkan ke versi OS yang didukung, atau menilai risiko dan menandai kerentanan sebagai Ignored di konsol.

Apa cakupan dampak kerentanan OS ketika beberapa layanan di-deploy pada server yang sama?

Ketika beberapa layanan di-deploy pada server yang sama, kerentanan OS memengaruhi semua layanan di server tersebut karena mereka berbagi lingkungan OS yang sama. Kami merekomendasikan menerapkan patch sistem ke seluruh server dan membuat cadangan snapshot sebelum perbaikan.

Apakah saya perlu me-restart server setelah memperbaiki kerentanan? Apa dampaknya terhadap bisnis?

• Kerentanan sistem Windows: Restart server diperlukan agar patch berlaku. Restart menyebabkan gangguan layanan singkat. Kami merekomendasikan melakukan operasi ini pada jam sepi dan memilih Automatically Create Snapshot and Fix Risk untuk rollback.

• Kerentanan kernel Linux: Restart diperlukan. Jika status tetap Fixed and Pending Restarted setelah perbaikan, klik Restart di konsol atau restart server secara manual, lalu klik Verify.

• Kerentanan perangkat lunak Linux: Biasanya tidak perlu restart, kecuali advis kerentanan secara eksplisit menyatakan Restart required.

• Contoh CVE spesifik: Untuk CVE-2024-57979, jika konsol tidak menunjukkan bahwa restart diperlukan, maka tidak perlu restart.

• Dampak bisnis: Restart menyebabkan gangguan layanan; proses perbaikan mungkin mengonsumsi sumber daya sehingga menyebabkan kelambatan. Kami merekomendasikan membuat cadangan (snapshot) dan menguji terlebih dahulu di lingkungan pengujian.

Apa risiko tidak memperbaiki kerentanan berisiko tinggi (seperti ptrace kernel Linux)?

• Risiko: Kerentanan eskalasi hak istimewa lokal berisiko tinggi (seperti CVSS 7.8) dapat dieksploitasi oleh penyerang untuk mencuri file sensitif (/etc/shadow, kunci privat SSH) dan mendapatkan akses root, yang mengarah pada kompromi penuh server.

• Mitigasi: Jika perbaikan segera tidak memungkinkan, batasi akses melalui grup keamanan dan perkuat pemantauan, tetapi perbaikan utama tetap berupa penerapan patch.

• Lokasi kerentanan SSL/TLS: Untuk kerentanan pengungkapan informasi SSL/TLS (seperti CVE-2016-2183), Anda dapat melakukan ping ke domain untuk menyelesaikan IP, lalu menggunakan sumber daya CLB/K8s untuk menemukan node yang terpengaruh guna remediasi manual.

Apakah efek perbaikan otomatis patch Windows oleh Security Center sama dengan mengunduh dan menginstalnya secara manual?

Ya. Fitur perbaikan Security Center memanggil antarmuka tingkat sistem untuk menginstal patch resmi Microsoft, menghasilkan hasil yang sama dengan unduhan dan instalasi manual.

Apakah Security Center mendukung pembuatan dan ekspor laporan pemindaian kerentanan?

• Laporan kerentanan aplikasi: Versi pay-as-you-go perlu ditingkatkan ke Comprehensive Host Protection atau lebih tinggi untuk mendukung pemindaian kerentanan aplikasi. Di konsol, buka Risk Governance > Vulnerabilities > Application Vulnerability untuk melihat dan mengekspor daftar. Laporan independen untuk URL website tidak didukung.

• Kerentanan instance ECS spesifik: Buka Assets > Host, cari server target, masuk ke halaman detail, dan klik Vulnerability Details > Application Vulnerability untuk melihat dan mengekspor.

• Verifikasi sumber laporan: Periksa apakah bidang Scan tool menunjukkan Alibaba Cloud Security Center dan jenis laporan mencakup Host vulnerability scan.

• Laporan kerentanan berisiko tinggi (seperti Nacos): Lihat peristiwa manajemen di modul Security Management di konsol.

Bagaimana cara menentukan apakah versi kernel Linux saya terpengaruh oleh CVE tertentu?

1. Jalankan uname -r untuk memeriksa versi kernel saat ini dan bandingkan dengan rentang versi yang terpengaruh dalam advis CVE.

2. Contoh: Jika CVE memengaruhi versi kernel 4.14 hingga 6.18.21 dan 6.19.11, dan versi saat ini adalah 3.10.0, server tidak terpengaruh.

3. Kunjungi halaman pengumuman resmi risiko dan perbaikan kerentanan Alibaba Cloud untuk detail dampak spesifik.

Apa urutan eksekusi dan saran konkurensi untuk perbaikan kerentanan batch?

• Urutan eksekusi: Kerentanan perangkat lunak Linux diperbaiki sesuai urutan daftar di konsol. Kerentanan sistem Windows memprioritaskan patch prasyarat terlebih dahulu.

• Konkurensi: Tunggu hingga batch sebelumnya selesai sebelum memulai yang berikutnya untuk menghindari konflik sumber daya.

• UI tidak merespons: Jika UI menunjukkan Sending command tanpa respons, ini mungkin keterlambatan tampilan. Refresh halaman secara manual untuk melihat status Fixing.

• Durasi: Perbaikan otomatis Linux biasanya memakan waktu beberapa menit hingga puluhan menit tergantung jumlah kerentanan, kinerja server, dan jaringan. Jika terlalu lama, periksa ruang disk (disarankan 3 GB atau lebih), konflik manajer paket, atau masalah izin.

Apakah Security Center mendukung perbaikan kerentanan untuk server tanpa alamat IP publik?

Ya. Selama server memiliki Agen Security Center yang terinstal dan konektivitas jaringan normal, perbaikan kerentanan didukung. Saat menggunakan sumber internal Alibaba Cloud, IP publik tidak diperlukan. Prasyarat: Layanan Security Center harus diaktifkan dan Agen harus online.

Apa pertimbangan untuk mengaktifkan perbaikan kerentanan otomatis?

• Tidak diaktifkan secara default: Perbaikan otomatis memerlukan konfigurasi kebijakan manual sebelum berlaku.

• Batasan cakupan: Hanya mendukung kerentanan sistem Linux non-kernel dan bergantung pada fitur perbaikan satu klik (dukungan versi diperlukan).

• Rekomendasi: Uji terlebih dahulu di lingkungan pengujian. Pastikan kebijakan cadangan snapshot dikonfigurasi. Jadwalkan pada jam sepi. Hindari mengaktifkan untuk semua aset untuk mencegah konsumsi kuota perbaikan yang berlebihan.

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

Beberapa kerentanan, terutama kerentanan kernel Linux, memerlukan restart. Di halaman detail kerentanan, klik Restart. Setelah restart, klik Verify. Jika status menunjukkan Fixed and Pending Restarted, perbaikan berhasil.

Host belum menginstal patch tertentu, tetapi kerentanan Windows menunjukkan telah diperbaiki. Mengapa?

Ini merupakan hal yang diharapkan. Pembaruan keamanan Windows bersifat kumulatif: setiap patch bulanan mencakup semua perbaikan sebelumnya. Ketika Security Center mendeteksi pembaruan kumulatif terbaru, sistem menandai semua kerentanan lama yang dicakup oleh pembaruan tersebut sebagai telah diperbaiki.

Untuk mengonfirmasi apakah kerentanan lama tertentu dicakup, kunjungi situs web patch resmi Microsoft dan cari patch terbaru yang diinstal berdasarkan nomor KB-nya. Periksa detail paketnya untuk memverifikasi cakupan.

Setelah memperbaiki kerentanan, mengapa masih menunjukkan "Not fixed"?

Tiga kemungkinan penyebab:

1. Keterlambatan verifikasi: Setelah perbaikan manual, klik Verify untuk memicu pemindaian instan. Pembaruan status memerlukan beberapa menit.

2. Cache konsol: Refresh halaman secara paksa atau tunggu beberapa menit.

3. Perbaikan tidak lengkap: Perbaikan mungkin tidak sepenuhnya berhasil, atau mungkin ada beberapa jalur kerentanan dengan hanya satu yang diperbaiki. Periksa ulang langkah-langkah perbaikan.

Apakah Security Center dapat secara otomatis memverifikasi kerentanan dalam status "Fixed and Pending Restart"?

Tidak. Restart server dari Konsol Security Center atau secara manual, lalu klik Verify untuk mengonfirmasi apakah perbaikan berhasil.

Mengapa tidak ada respons saat saya memverifikasi secara manual setelah memperbaiki kerentanan?

Dua kemungkinan penyebab:

• Tingkat pemindaian tidak dikonfigurasi: Security Center hanya memperbarui kerentanan yang tingkat keparahannya dipilih di Vulnerability Settings. Verifikasi bahwa tingkat pemindaian mencakup kerentanan target.

• Agen offline: Fungsi Verify memerlukan koneksi langsung antara konsol dan agen. Jika agen offline, atasi terlebih dahulu masalah konektivitas, lalu coba lagi.

Bagaimana cara melihat notifikasi kegagalan setelah perbaikan kerentanan gagal?

Cara melihat: Di halaman Vulnerabilities di Konsol Security Center, klik angka di bawah Fixing. Di panel Fixing, temukan kerentanan yang gagal dan klik ikon di kolom Status untuk melihat notifikasi kegagalan di kotak dialog Cause Details.

Isi notifikasi: Notifikasi kegagalan menunjukkan alasan spesifik kegagalan perbaikan, kode kesalahan yang sesuai (jika tersedia), dan tindakan yang disarankan.

Bagaimana cara menangani kode kesalahan dalam notifikasi kegagalan perbaikan?

Ikuti solusi yang disediakan dalam dokumentasi Troubleshoot causes of vulnerability fixing failures untuk kode kesalahan spesifik yang ditampilkan dalam notifikasi kegagalan.

Apakah memperbaiki kerentanan secara manual menyebabkan Security Center menghasilkan peringatan serangan false positive?

Tidak. Memperbarui patch kerentanan secara manual tidak menyebabkan Security Center menghasilkan peringatan serangan false positive. Jika konsol masih menunjukkan Unfixed setelah remediasi manual, klik tombol Verify atau tunggu hingga status data diperbarui secara otomatis.

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

1. Konfirmasi kernel telah di-upgrade. Jalankan perintah berikut untuk memeriksa versi kernel yang sedang berjalan dan verifikasi apakah memenuhi persyaratan dalam detail kerentanan: Konfirmasi sistem memulai menggunakan kernel baru:

      uname -av
      cat /proc/version

      cat /etc/grub.conf

2. Hapus paket kernel lama. Daftar semua paket kernel yang diinstal dan identifikasi versi lama: Hapus paket kernel lama: Atau, gunakan metode yang direkomendasikan distribusi. Untuk CentOS/Red Hat:

   Penting

   Sebelum menghapus paket kernel lama, buat snapshot atau image untuk instance saat ini di konsol Elastic Compute Service.

      rpm -qa | grep kernel

      rpm -e kernel-<old_version_number>

      yum remove kernel-<old_version_number>

3. Abaikan peringatan (opsional). Jika kernel yang sedang berjalan telah memperbaiki kerentanan, abaikan peringatan tersebut:

   1. Masuk ke Masuk ke Konsol Security Center.

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

   3. Di tab Linux Software Vulnerability, temukan kerentanan dan klik namanya.

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

Bagaimana cara memperbarui kernel Ubuntu secara manual?

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

1. Konfirmasi versi kernel saat ini adalah 3.1*:

      uname -av

2. Periksa 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, jalankan apt-get update untuk mengambil daftar paket terbaru.

4. Instal pembaruan 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. Restart server untuk menerapkan kernel baru.

6. Setelah server restart, verifikasi pembaruan kernel:

      uname -av

      dpkg -l | grep linux-image

Apa yang harus saya lakukan jika mendapatkan notifikasi ketidakcocokan kernel saat memperbaiki kerentanan kernel?

Gejala: Setelah menjalankan perbaikan satu klik untuk kerentanan kernel di Konsol Security Center, perbaikan gagal dan notifikasi kegagalan menunjukkan error ketidakcocokan kernel.

Penyebab: Versi kernel server tidak kompatibel dengan versi perbaikan target. Hal ini dapat terjadi jika kernel dimodifikasi secara manual, menggunakan versi non-standar, atau celah versi terlalu besar untuk upgrade normal.

Resolusi:

Solusi 1: Gunakan perbaikan paksa

Jika Anda yakin beban kerja Anda tidak akan terpengaruh, gunakan perbaikan paksa untuk melewati pemeriksaan kompatibilitas:

1. Tutup kotak dialog notifikasi kegagalan.

2. Di bagian Unhandled Vulnerabilities, klik Fix di kolom Actions untuk server target.

3. Di kotak dialog yang muncul, pilih kotak centang Mandatory Fix.

4. Pilih metode remediasi dan klik Fix Now.

   Penting

   Perbaikan paksa melewati pemeriksaan kompatibilitas klien, yang mungkin menimbulkan risiko. Kami merekomendasikan memilih Automatically Create Snapshot and Fix Risk untuk mempertahankan kemampuan rollback.

5. Klik Fix Now.

Solusi 2: Perbarui kernel secara manual

Jika perbaikan paksa tidak sesuai, rujuk Bagaimana cara memperbarui kernel Ubuntu secara manual? untuk langkah upgrade manual.

Kapan saya dapat menggunakan perbaikan paksa? Apa risikonya?

Kapan digunakan: Perbaikan paksa berlaku ketika:

• Perbaikan satu klik gagal karena ketidakcocokan kernel.

• Anda yakin lingkungan sistem memenuhi persyaratan perbaikan tetapi pemeriksaan kompatibilitas tidak lolos.

Cara menggunakan: Pilih kotak centang Mandatory Fix di kotak dialog perbaikan.

Risiko: Perbaikan paksa melewati pemeriksaan kompatibilitas, yang dapat menyebabkan:

• Masalah kompatibilitas setelah perbaikan yang dapat mengganggu bisnis.

• Kegagalan upgrade kernel yang dapat mencegah sistem booting secara normal.

Rekomendasi: Sebelum menggunakan perbaikan paksa, pilih Automatically Create Snapshot and Fix Risk untuk rollback cepat. Gunakan perbaikan paksa hanya jika Anda yakin beban kerja Anda tidak akan terpengaruh.

Apa yang harus saya lakukan jika kerentanan menunjukkan tidak ada pembaruan yang tersedia?

Tidak ada patch resmi yang tersedia

Ketika perintah pembaruan mengembalikan pesan seperti already installed and latest version atau No Packages marked for Update, sumber pembaruan resmi belum merilis patch. Hal ini dapat memengaruhi paket seperti Gnutls, Libnl, dan MariaDB. Tunggu hingga sumber perangkat lunak resmi merilis pembaruan.

Versi OS telah mencapai end of life (EOL)

Jika paket perangkat lunak merupakan versi terbaru yang didukung oleh sistem saat ini tetapi masih tidak memenuhi persyaratan perbaikan, versi OS mungkin telah melewati masa EOL-nya (misalnya, CentOS 6.x). Dua opsi:

• Upgrade OS ke versi yang masih dalam masa dukungan resmi.

• Setelah menilai risiko dan mengonfirmasi bahwa risiko tersebut dapat dikelola, abaikan kerentanan di Konsol Security Center.

Bagaimana cara menangani timeout saat menghubungkan ke sumber Yum Alibaba Cloud?

Jika koneksi timeout, muncul error seperti berikut:

[Errno 12] Timeout on http://mirrors.aliyun.com/centos/6/os/x86_64/repodata/repomd.xml: (28, 'connect() timed out!')

1. Periksa apakah resolusi DNS berfungsi. Jalankan ping mirrors.aliyun.com atau nslookup mirrors.aliyun.com.

2. Jika akses jaringan normal, tunggu sebentar dan coba lagi. Timeout mungkin disebabkan oleh fluktuasi jaringan sementara atau trafik tinggi pada sumber mirror.

Bagaimana cara menghapus paket patch kerentanan Windows dari direktori klien?

Setelah perbaikan satu klik, agen secara otomatis mengunduh, menginstal, dan menghapus paket patch.

Jika patch tetap ada setelah 3 hari, hapus secara manual:

1. Masuk ke Masuk ke Konsol Security Center.

2. Di panel navigasi sebelah kiri, pilih System Settings > Feature Settings. Di pojok kiri atas konsol, pilih wilayah tempat aset Anda di-deploy: Chinese Mainland atau Outside Chinese Mainland.

3. Jika perlindungan diri klien diaktifkan, buka halaman detail server di Asset Center dan matikan toggle Client Protection.

   Catatan

   Perlindungan diri klien memblokir permintaan untuk menghapus atau mengunduh file proses dari direktori agen pada server Windows. Jika Anda belum mengaktifkan perlindungan diri klien, lewati langkah ini.

4. Login ke server Windows dengan izin administrator dan hapus paket patch dari direktori berikut:

   Penting

   Path default paket patch adalah C:\Program Files (x86)\Alibaba\Aegis\globalcfg\hotfix.

5. (Opsional) Di halaman detail server, aktifkan kembali Client Protection.

Apakah path kerentanan yang menunjukkan "none" dalam hasil pemindaian Security Center memerlukan tindakan?

Hal ini biasanya menunjukkan bahwa kerentanan terdeteksi tetapi path file spesifik tidak dapat ditemukan. Ini merupakan perilaku normal dan tidak memerlukan tindakan khusus.

Apakah paket sumber daya perbaikan kerentanan Security Center berlangganan otomatis atau perlu diaktifkan secara manual?

Pengguna perlu mengklaimnya secara manual di konsol agar berlaku. Paket tersebut tidak berlangganan atau diaktifkan secara otomatis secara default.

FAQ pengajuan pemindaian penetrasi dan kerentanan

• Kegagalan pengajuan aplikasi: Pastikan Anda hanya memasukkan alamat IP sumber publik yang sebenarnya (mesin yang memulai pemindaian), bukan IP server target yang dipindai.

• Prompt "Not my asset" saat menambahkan IP: Hal ini biasanya berarti IP tersebut dimiliki oleh Akun Alibaba Cloud lain. Beralihlah ke akun yang memiliki IP tersebut dan ajukan aplikasi dari akun tersebut.

• Konfigurasi alat pemindaian pihak ketiga: Tambahkan IP alat pemindaian pihak ketiga ke daftar putih di platform manajemen keamanan dan ajukan aplikasi pengujian penetrasi.

Mengapa saya masih dikenai biaya untuk pemindaian terjadwal setelah membatalkan layanan berbayar?

Fitur pay-as-you-go mungkin masih diaktifkan. Solusi:

1. Login ke Konsol Security Center.

2. Di panel navigasi sebelah kiri, pilih Overview untuk membuka halaman Ikhtisar.

3. Di bagian Pay-as-you-go di pojok kanan atas halaman, Anda dapat:

   • Menonaktifkan layanan tertentu: Matikan sakelar untuk layanan yang sesuai untuk menghentikan penagihan hanya untuk layanan tersebut.

   • Menonaktifkan semua layanan sekaligus: Klik tombol Disable All Pay-as-you-go Services di pojok kanan atas halaman untuk menonaktifkan semua fitur pay-as-you-go sekaligus.

4. Isi ulang dan selesaikan saldo yang belum dibayar untuk mencegah dampak pada layanan lain.

Bagaimana cara mengkueri log operasi Security Center di ActionTrail?

Gunakan konsol ActionTrail di ActionTrail console - Security Center events. Jika tidak ada data yang dikembalikan, periksa pengaturan wilayah di konsol ActionTrail — beralihlah ke wilayah tempat sumber daya berada (misalnya, Shanghai), karena log operasi mungkin disimpan di wilayah berbeda.

Mengapa path deteksi kerentanan mendesak CVE-2019-14439 tidak menampilkan lingkungan kontainer?

Masalah: Path deteksi kerentanan mendesak CVE-2019-14439 tidak menampilkan lingkungan kontainer. Path-nya adalah /skywalking/oap-libs/jackson-databind-2.9.5.jar. Lingkungan yang ditemukan di server adalah lingkungan kontainer, tetapi lingkungan lokal tidak berisi pustaka Jackson. Sebagai perbandingan, kerentanan eksekusi kode remote Spring Framework JDK >= 9 (juga kerentanan mendesak) menunjukkan keberadaannya di kontainer.

Jawaban: Skrip deteksi bervariasi tergantung jenis kerentanan. Untuk skenario yang memerlukan pemindaian lingkungan kontainer, kami merekomendasikan menggunakan alat pemindaian kerentanan aplikasi.

Bagaimana cara mengkueri CVE yang diperbaiki oleh patch bulanan Windows?

1. Login ke Konsol Security Center.

2. Di panel navigasi sebelah kiri, pilih Risk Governance > Vulnerabilities, pilih tab Windows System Vulnerability, dan dapatkan nomor patch yang perlu Anda kueri (misalnya, patch 5043050).

3. Kunjungi tautan patch Microsoft dan ganti nomor patch di akhir dengan yang perlu Anda kueri. Contoh: https://support.microsoft.com/help/5043050

4. Di halaman yang terbuka, klik xx Month xx Security Update untuk melihat daftar CVE yang diperbaiki oleh paket KB tersebut.

5. Bandingkan daftar CVE dengan daftar CVE yang ditampilkan di kolom CVE ID di Security Center untuk memastikan konsistensi.