Cara Mengaudit Linux VPS dengan vps-audit—dan Membaca Hasilnya dengan Benar

Audit VPS Cepat Adalah Titik Awal, Bukan Putusan

Website Anda memuat dan SSH merespons, tetapi itu tidak mengungkapkan pembaruan yang tertunda, pengaturan SSH yang permisif, atau pendengar yang tidak terduga. Audit lintasan pertama mengungkap pertanyaan-pertanyaan tersebut.

vps-audit adalah daftar periksa Bash untuk Debian dan Ubuntu yang mengubah sinyal konfigurasi lokal, pemeliharaan, pendengar, dan sumber daya menjadi laporan berkode warna. Seperti dasbor kendaraan, ini menunjukkan area yang memerlukan inspeksi tanpa mendiagnosis setiap penyebab.

Panduan ini dengan aman menjalankan vps-audit v0.2.0 yang disematkan, memeriksa hasil penting dengan alat asli, dan mengubahnya menjadi prioritas. Contoh menggunakan satu VPS Ubuntu AlexHost yang menjalankan Ubuntu 24.04 LTS. Gambar penyedia lain mungkin berbeda, dan sistem operasi tamu yang tidak dikelola tetap menjadi tanggung jawab operator.

Apa yang Diperiksa vps-audit—dan Apa yang Tidak Dapat Dibuktikan

vps-audit memeriksa indikator lokal tanpa menguji area apa pun secara menyeluruh. Tabel ini menunjukkan apa yang dapat—dan tidak dapat—diberitahukan oleh setiap hasil.

SUID memungkinkan program berjalan dengan hak istimewa efektif pemilik file. Program sistem yang sah menggunakannya, jadi selidiki file SUID yang tidak terduga daripada menghapusnya. Fail2ban dan CrowdSec dapat memblokir lalu lintas yang bermusuhan, tetapi instalasi atau status aktif saja tidak membuktikan bahwa mereka melindungi layanan yang dimaksudkan.

Skrip menerapkan ambang batas generik untuk penggunaan sumber daya, layanan, login yang gagal, dan pendengar. Ini bukan skor risiko yang menyadari beban kerja; peran VPS yang berbeda dapat mencapai warna yang sama karena alasan yang berbeda.

Alat ini tidak memeriksa malware, kerentanan yang diketahui, aplikasi, kontainer, firewall penyedia, kepatuhan, atau tren. Meskipun README-nya menyebutkan “Active Internet Connections,” v0.2.0 hanya mengambil IP publik dan menginventarisasi pendengar lokal. Karena memerlukan visibilitas istimewa, pertama-tama kontrol file mana yang menerima akses sudo.

Sebelum Anda Memberikan sudo pada Script yang Diunduh

Alur kerja Debian/Ubuntu ini memerlukan akses SSH, sudo, dan alat standar yang digunakan di bawah. Bekerja di direktori yang dapat dibuang. Jika alat hilang, berhenti daripada mengubah baseline dengan menginstalnya.

Contoh menggunakan vps-audit v0.2.0, dipublikasikan pada 10 Agustus 2026 dan masih terbaru saat diperiksa pada 8 September 2026.

Tagnya menunjuk ke commit 57c323d46b48026740f0b35b9bad6cd6127c757b. Pinning menghindari perubahan kemudian dari main yang dapat berubah.

Buat direktori khusus dan unduh script yang ditandai dengan tepat melalui HTTPS:

mkdir -p "$HOME/vps-audit-test"
cd "$HOME/vps-audit-test"
curl -fL --proto '=https' --tlsv1.2 
  -o vps-audit.sh 
  https://raw.githubusercontent.com/nuver-labs/vps-audit/v0.2.0/vps-audit.sh

Ini menyimpan vps-audit.sh di direktori baru. Opsi -f gagal pada kesalahan HTTP, sementara -L mengikuti pengalihan.

Selanjutnya, catat sidik jari SHA-256 lokal dan tampilkan pengaturan yang relevan dengan panduan ini:

sha256sum vps-audit.sh
grep -nE '^(VPS_AUDIT_VERSION|RESOURCE_(WARN|FAIL)|SERVICES_(WARN|FAIL)|LOGINS_(WARN|FAIL)|OPEN_PORTS_(WARN|FAIL)|PASSWORD_MINLEN|DEFAULT_REPORT_DIR|ENABLE_CHOWN)=|api.ipify.org' vps-audit.sh

Output sidik jari file dan menunjukkan jalur laporannya, ambang batas, dan permintaan ke api.ipify.org. Sumber lengkap yang ditandai juga membaca status lokal, mensimulasikan apt-get -s upgrade, dan mencari file SUID secara rekursif. Ini bukan hanya-baca: ia menulis laporan, dapat membuat direktorinya, dan menghubungi layanan eksternal. Tinjau sumber sebelum memberikan hak istimewa yang ditingkatkan jika Anda dapat membaca kode shell.

Ambang batas sumber daya adalah 50% untuk WARN dan 80% untuk FAIL. Layanan yang berjalan menggunakan 20/40, login yang gagal 10/50, pendengar secara nominal 10/20, dan panjang kata sandi 12. Bagian keterbatasan menjelaskan mengapa status pendengar tidak mengikuti variabel tersebut.

⚠️ Peringatan: Pinning, hashing, inspeksi tertarget, dan pemeriksaan sintaks meningkatkan reproduksibilitas tetapi tidak membangun kepercayaan. Commit tidak ditandatangani, dan rilis tidak menyediakan aset checksum atau signature.

Simpan hash dengan catatan audit. Sebelum menjalankan, bandingkan dengan file. Kecocokan menunjukkan bahwa salinan berisi byte yang sama. Perbedaan mungkin berasal dari rilis lain, unduhan yang berubah, atau edit lokal. Merekam tag dan hash menghubungkan setiap laporan dengan script yang menghasilkannya.

Terakhir, parse file tanpa menjalankan perintah normalnya, kemudian tambahkan izin eksekusi hanya jika parsing berhasil:

bash -n vps-audit.sh 
  && chmod +x vps-audit.sh 
  && printf 'Syntax check: PASS; execute permission addedn'

Ini hanya mengkonfirmasi bahwa Bash dapat mem-parse file dan bahwa izin eksekusi ditambahkan. Script yang disematkan sekarang siap untuk satu kali berjalan tanpa perubahan.

Jalankan vps-audit dan Temukan Laporan

Skrip mencetak detail sistem dan status berwarna, kemudian menulis laporan teks biasa. Pencarian SUID rekursifnya membuat runtime bervariasi, jadi ukurlah.

Jalankan file yang disematkan sekali dan pertahankan status keluar proses shell:

printf 'Audit started: '
date -u '+%Y-%m-%d %H:%M:%S UTC'
TIMEFORMAT=$'Elapsed real: %3R secondsnUser CPU: %3U secondsnSystem CPU: %3S seconds'
time sudo ./vps-audit.sh
AUDIT_STATUS=$?
printf 'Audit exit status: %sn' "$AUDIT_STATUS"

Pada VPS yang diuji, audit dimulai pada 13:12:10 UTC pada 14 September 2026 dan selesai dalam 58.412 detik. Ini mengembalikan 0 dan menyimpan ./vps-audit-report-20260914_131210.txt.

Elapsed real adalah waktu dinding jam; nilai pengguna dan sistem mengukur waktu CPU. Status keluar 0 berarti proses selesai, bukan bahwa setiap pemeriksaan lulus. v0.2.0 mengembalikan 0 bahkan dengan hasil FAIL.

Pilih laporan baru, periksa metadatanya, dan ekstrak hitungan dan contoh tanpa menampilkan file sensitif secara penuh.

REPORT=$(ls -1t ./vps-audit-report-*.txt 2>/dev/null | head -n 1)
if [ -z "$REPORT" ]; then
    printf 'No vps-audit report found in the current directory.n' >&2
    exit 1
fi
printf 'Report selected: %sn' "$REPORT"
sudo stat --format='Owner: %U:%G | Mode: %A (%a) | Size: %s bytes | Modified: %y' "$REPORT"

for status in PASS WARN FAIL; do
    count=$(sudo grep -c "^\[$status\]" "$REPORT" || true)
    printf '%s: %sn' "$status" "$count"
done

sudo grep -E '^[(PASS|WARN|FAIL)] (Running Services|Disk Usage|Password Policy)' "$REPORT"

Waktu modifikasi laporan 13:13:08 UTC cocok dengan jalannya. Ini berisi 17 hasil: enam PASS, tiga WARN, dan delapan FAIL. Ini adalah klasifikasi, bukan skor keamanan.

Total status berguna saat membandingkan jalannya versi yang sama, tetapi selalu periksa baris di balik perubahan. Hitungan FAIL yang lebih rendah mungkin berasal dari input berbeda atau perilaku pengurai daripada peningkatan. Total yang tidak berubah juga dapat menyembunyikan satu masalah yang diselesaikan dan satu masalah baru.

Laporan 2.665 byte milik root:root dengan mode 644 (-rw-r--r--), seperti yang diharapkan dengan sudo dan ENABLE_CHOWN=false standar. Pengguna grup dan lainnya dapat membaca mode itu jika izin direktori memungkinkan mereka mencapai file. Kepemilikan root saja tidak membuatnya pribadi.

❗ Penting: Laporan berisi nama host, IP publik, detail sistem, dan temuan. Jaga agar tetap pribadi, dan redaksi pengenal, prompt, dan informasi layanan sensitif sebelum berbagi.

Jika jalannya di masa depan kekurangan satu status, catat ketiadaan itu daripada mengonfigurasi ulang VPS untuk menghasilkan warna.

Cara Membaca PASS, WARN, dan FAIL Tanpa Bereaksi Berlebihan

Label dashboard melaporkan bagaimana setiap test cocok dengan aturan v0.2.0:

Pisahkan pengamatan dari rekomendasi. Dalam “22 layanan berjalan,” jumlahnya adalah pengamatan; “kurangi permukaan serangan” adalah saran berdasarkan ambang batas generik. Konfirmasi jumlahnya, identifikasi layanannya, dan kemudian putuskan apakah saran itu sesuai untuk server.

Tanyakan tiga pertanyaan untuk setiap hasil: Apakah nilainya akurat? Apakah itu disengaja? Apa dampak realistisnya? Perintah asli memeriksa nilainya; konteks beban kerja menentukan sisanya.

WARN port SSH berbasis kebijakan: v0.2.0 menandai port 22. Memindahkan SSH dapat mengurangi kebisingan otomatis tetapi tidak dapat menggantikan autentikasi kuat atau kontrol akses. Layanan yang dikenal di port 22 mungkin kurang penting daripada pendengar wildcard yang tidak dikenal.

Untuk FAIL, periksa aturan sebelum mengusulkan perbaikan. Tes root-login hanya menerima PermitRootLogin no, jadi pengaturan prohibit-password yang berbeda masih gagal. Periksa OpenSSH secara langsung sebelum bertindak.

PASS juga memerlukan konteks. Untuk unattended-upgrades, skrip hanya mengkonfirmasi bahwa paket ada—bukan konfigurasi atau riwayat jalannya.

Verifikasi Temuan Berdampak Tinggi dengan Perintah Native

Gunakan perintah native read-only untuk memeriksa akses SSH, host filtering, dan local listeners. Pertama, tanyakan apa yang sebenarnya OpenSSH resolve setelah defaults dan included configuration digabungkan:

sudo sshd -T 
  | grep -E '^(port|listenaddress|permitrootlogin|passwordauthentication|kbdinteractiveauthentication|pubkeyauthentication) '

Ubuntu memuat /etc/ssh/sshd_config.d/*.conf di dekat awal konfigurasi utamanya. sshd -T resolve pengaturan gabungan, menjadikannya bukti yang lebih kuat daripada grep satu file.

OpenSSH resolve port 22 pada wildcard IPv4 dan IPv6 addresses. Ini juga mengembalikan permitrootlogin yes, passwordauthentication yes, pubkeyauthentication yes, dan kbdinteractiveauthentication no. Konfigurasi yang di-resolve mengkonfirmasi temuan root-login dan password-authentication script, meskipun account state, PAM, dan Match rules masih dapat mempengaruhi login tertentu.

Kedua, tanyakan apa yang UFW sendiri laporkan tentang state dan managed policy-nya:

sudo ufw status verbose

Ubuntu mendokumentasikan UFW sebagai default firewall frontend-nya. Di sini aktif dengan low-level logging dan default-deny policies untuk incoming dan routed traffic. Rules mengizinkan inbound ports 22, 80, 443, dan 37985 melalui IPv4 dan IPv6. Ini mengkonfirmasi state UFW, bukan apakah setiap rule sesuai.

Ketiga, inventarisasi local TCP dan UDP listeners, bind addresses, dan owning processes:

sudo ss -lntup

Opsi memilih numeric TCP dan UDP listeners dan meminta process details. Ports 53, 62789, 8404, dan 11111 adalah loopback-only; ports 22, 80, 2096, 5678, dan 37985 menggunakan wildcard addresses. Tidak ada process details yang muncul, jadi owners dan purposes mereka tetap tidak diketahui.

process listener
    → bind address / interface
    → host firewall
    → provider-edge firewall or NAT
    → external network path

Ports 22, 80, dan 37985 memiliki wildcard listeners dan UFW allow rules. UFW mengizinkan 443 tanpa listener, sementara 2096 dan 5678 memiliki listeners tanpa displayed allow rules.

Firewall rule dan listener menjawab pertanyaan berbeda. Rule mengizinkan traffic jika service ada untuk menerimanya; listener menunjukkan service menunggu, tetapi bukan apakah network traffic dapat mencapainya. Membaca keduanya bersama-sama mempersempit investigasi tanpa mengklaim external exposure.

📝 Catatan: ss menunjukkan local bind state, dan UFW menunjukkan satu host firewall. Keduanya tidak membuktikan Internet reachability di seluruh provider firewalls atau NAT; itu memerlukan authorized testing dari sistem lain.

v0.2.0 bagaimanapun melabeli daftar yang sama “Total” dan “Public” setelah membuang bind addresses, meskipun empat dari sembilan TCP ports adalah loopback-only. Filter LISTEN-nya juga melewatkan UDP rows yang ditandai UNCONN. Baca hasil ini sebagai local TCP port count, bukan public exposure.

Ubah Temuan Terverifikasi menjadi Antrian Tindakan Praktis

Tetapkan prioritas berdasarkan kepercayaan diri, eksposur, dampak, dan niat. Priority 1 mencakup kelemahan yang dikonfirmasi yang memerlukan tindakan. Priority 2 mencakup temuan penting yang masih memerlukan investigasi, sementara Priority 3 mencakup item berisiko rendah atau yang didorong kebijakan. Jika pengaturan disengaja, dokumentasikan alasannya, kontrol kompensasi apa pun, dan kapan harus meninjau ulang.

Tabel menerapkan pendekatan itu untuk jalankan ini; bukti yang tidak lengkap membuat prioritas tetap sementara:

Priority 2 tidak berarti tidak berbahaya; bukti tetap tidak lengkap. Berikan setiap item yang belum terselesaikan pemilik dan tenggat waktu. Promosikan jika verifikasi mengkonfirmasi eksposur atau kelemahan. Jika disengaja dan dikendalikan, catat keputusan dengan jelas.

Label laporan tidak menetapkan urutan: verifikasi dan konteks yang melakukannya.

⚠️ Peringatan: Jangan ubah autentikasi SSH atau aturan firewall jarak jauh dari urutan perintah ini. Kesalahan dapat mengunci Anda. Sebelum remediasi, konfirmasi akses kunci yang teruji dan validasi konfigurasi baru. Biarkan sesi kedua tetap terbuka dan pastikan akses konsol atau pemulihan berfungsi.

Tangani setiap remediasi sebagai alur kerja terpisah. Petakan dependensi sebelum menghentikan layanan, klasifikasikan pembaruan sebelum menjadwalkannya, dan verifikasi kepemilikan dan checksum sebelum mengubah izin SUID.

Di Mana Pandangan vps-audit Berhenti

vps-audit v0.2.0 adalah daftar periksa Bash pada saat tertentu. Ini tidak dapat membangun eksposur eksternal, mendeteksi kerentanan atau malware, memeriksa workload, menganalisis log yang disimpan, atau memberikan pemantauan berkelanjutan. Ini bukan tes penetrasi atau penilaian CIS Benchmark.

Kode menambahkan peringatan penting.

• Status port menjadi PASS di bawah tiga port TCP yang diurai, WARN pada tiga atau empat, dan FAIL pada lima atau lebih—meskipun variabel nominal 10/20.
• PASS unattended-upgrades hanya memeriksa paket, bukan konfigurasi, timer, atau riwayat jalannya.
• Tes pembaruan menggunakan metadata cache untuk apt-get -s upgrade umum, kemudian memanggil setiap paket yang terdaftar sebagai “pembaruan keamanan.”

Tes sudo-logging hanya membaca /etc/sudoers, melewatkan /etc/sudoers.d/ dan catatan journal atau syslog normal. Issue #33, terbuka saat diperiksa pada 8 September 2026, mendokumentasikan FAIL palsu ini pada Ubuntu 20.04 dan 24.04. Parsing juga dapat gagal dengan output non-Inggris, seperti yang dilacak dalam issue #37 yang terbuka. Meskipun wording README-nya, rilis ini tidak mencantumkan koneksi yang sudah terbentuk.

Perluas tinjauan saat diperlukan. Perilaku mencurigakan memerlukan analisis log yang disimpan dan workload. Untuk VPS penting, konfirmasi backup yang diuji dan pertimbangkan pengujian eksternal yang berwenang. Sistem kritis atau yang diatur mungkin memerlukan Lynis, CIS Benchmark Ubuntu 24.04, atau tinjauan profesional.

Bottom Line: Verifikasi, Prioritaskan, dan Periksa Ulang

Jaga laporan asli tetap pribadi dan pertahankan salinan yang disunting. Catat SHA-256 skrip, tag, dan commit bersama dengan waktu berjalan, layanan yang dimaksudkan, hasil verifikasi, dan antrian tindakan.

1. Verifikasi temuan berdampak tinggi dengan perintah native sebelum mengubah server.
2. Perbaiki masalah berisiko tinggi yang dikonfirmasi dengan aman, selidiki yang tidak diketahui, dan dokumentasikan pengecualian yang disengaja.
3. Jalankan kembali versi tertaut yang sama setelah perubahan atau sesuai jadwal, kemudian bandingkan laporan secara manual.

Saat membandingkan laporan, fokus pada perubahan autentikasi, aturan firewall, pendengar, dan temuan yang diselesaikan. Stempel waktu dan pembacaan sumber daya akan berubah. Catat perubahan yang disengaja sehingga peninjau berikutnya memahami mengapa hasilnya berbeda.

vps-audit tidak memiliki basis data baseline, penjadwal, analisis tren, atau mesin perbandingan. Nilainya berasal dari kebiasaan yang dapat diulang: jalankan, verifikasi, prioritaskan, dan periksa ulang.