View source for Cyber Security : Praktikum Uji CIA Triad dan Lembar Temuan

"Server kita aman kok." Kalimat itu keluar cepat, biasanya diikuti daftar alat: sudah pakai HTTPS, sudah ada sandi, sudah dipasang antivirus.

Masalahnya, "aman" bukan perasaan dan bukan daftar alat. Aman adalah klaim yang harus bisa dibuktikan orang lain, dengan perintah yang bisa diulang.

Artikel ini adalah versi praktik dari [[Cyber Security : CIA Triad dan Dasar Ancaman Siber]]. Kalau artikel pagi menjelaskan tiga pilar, artikel ini mengajakmu mengaudit satu layanan kecil sampai keluar angka, bukti, dan lembar temuan yang bisa diserahkan ke guru atau atasan.

== 🎯 Tujuan ==

Setelah menyelesaikan lab ini, kamu bisa:

* menyusun inventaris aset dan potret awal sebelum menilai apa pun;
* menguji kerahasiaan, integritas, dan ketersediaan dengan bukti yang bisa diulang;
* membedakan "layanan hidup" dari "layanan melayani";
* mengisi lembar temuan berskor dan menentukan prioritas perbaikan;
* membuktikan perbaikan tidak merusak pilar lain.

== 📍 Konteks nyata ==

Kepala sekolah bertanya: "Server nilai kita aman?" Jawaban admin: "Aman, Pak. Sudah pakai password dan HTTPS."

Kamu diminta memeriksa. Bukan membantah, tapi mencari bukti. Waktumu 40 menit sebelum rapat dimulai.

* 🔥 '''Kasus nyata:''' Sebuah SMK memakai satu server untuk aplikasi nilai dan folder arsip. Dalam 40 menit pemeriksaan ditemukan tiga hal. Berkas <code>config.bak</code> masih tertinggal di folder web dan bisa diunduh siapa saja lewat alamat <code>/config.bak</code>, lengkap dengan sandi database. Folder nilai punya izin baca untuk semua pengguna sistem. Dan saat ujian, layanan pernah "hidup" menurut panel monitoring, padahal tidak menjawab satu permintaan pun selama sebelas menit. Tiga temuan, tiga pilar, satu server yang disebut aman.

Yang menarik: tidak satu pun temuan itu butuh alat mahal. Semuanya butuh satu hal yang lebih langka, yaitu kebiasaan menguji klaim sendiri.

== 🧠 Konsep singkat ==

Audit keamanan adalah pekerjaan mengumpulkan bukti, bukan pekerjaan memberi opini. Badan standar NIST membagi metode pengumpulan bukti menjadi tiga: memeriksa (examine), mewawancarai (interview), dan menguji (test).

Dari tiga itu, hanya yang ketiga menghasilkan bukti keras. "Katanya sudah dikunci" adalah wawancara. "Saya coba buka dan ditolak" adalah uji.

{| class="wikitable"
! Tingkat bukti !! Bentuknya !! Kekuatannya
|-
| 1. Kesan || "kayaknya aman" || nol, tidak bisa diperiksa
|-
| 2. Klaim || dokumen, jawaban admin || lemah, bisa salah ingat
|-
| 3. Perintah || keluaran satu perintah || sedang, bisa berubah
|-
| 4. Perintah berulang || perintah dan hasil yang sama oleh orang lain || kuat, bisa diaudit
|}

Target lab ini bukan tingkat 3, tapi tingkat 4: orang lain bisa mengulang perintahmu dan mendapat hasil yang sama.

=== 🔹 Satu uji, satu pilar ===

Satu pengujian sebaiknya menjawab satu pertanyaan. Kalau hasilnya memukul dua pilar, catat sebagai dua baris temuan.

Contoh: menghentikan layanan memukul ketersediaan (layanan mati) dan bisa memukul integritas (transaksi setengah jalan). Dua baris, dua tindakan.

Aturan ini menjaga laporan tetap jujur. Laporan yang mencampur tiga pilar dalam satu baris biasanya berakhir dengan kesimpulan yang tidak bisa ditindaklanjuti.

=== 🔹 Skor dan bobot ===

Pakai rubrik sederhana yang sudah dipakai artikel konsep.

* Skor '''0''' — tidak ada kontrol.
* Skor '''1''' — kontrol ada, tapi belum pernah diuji.
* Skor '''2''' — kontrol ada dan terbukti lewat uji.

Skor saja belum cukup untuk menentukan urutan perbaikan. Kalikan dengan dampak: 3 untuk data nilai atau rekam medis, 2 untuk data internal, 1 untuk halaman publik.

* 📊 '''Angka penting:''' <code>python3 -m http.server</code> memakai port 8000 dan mendengarkan di semua antarmuka kalau tidak dibatasi. Karena itu lab ini selalu menulis <code>--bind 127.0.0.1</code> secara eksplisit. Satu argumen yang lupa ditulis bisa mengubah latihan lokal menjadi layanan terbuka.

=== 🔹 Tiga jebakan pengukuran ===

Sebagian besar audit gagal bukan karena alatnya kurang, tapi karena cara mengukurnya keliru.

* '''Akun uji terlalu tinggi.''' Menguji dengan root selalu lolos, karena root melewati hampir semua pemeriksaan izin. Ujilah dengan akun paling rendah yang realistis.
* '''Mtime dianggap bukti integritas.''' Waktu modifikasi bisa dikembalikan dengan satu perintah. Isi berubah, mtime tetap.
* '''Uji saat layanan menganggur.''' Layanan yang menjawab 200 dalam 5 milidetik saat sepi belum membuktikan apa pun tentang jam sibuk.

* ⚠️ '''Hati-hati:''' Jangan pernah menguji di server produksi, server sekolah, atau mesin orang lain tanpa izin tertulis. Lab ini memakai VM latihan yang boleh dirusak. Ambil snapshot dulu.

== 🧩 Istilah penting ==

* '''Aset''' — apa pun yang bernilai: berkas nilai, layanan web, akun, konfigurasi.
* '''Bukti (evidence)''' — perintah beserta keluarannya, disimpan apa adanya, bukan ringkasan ingatan.
* '''Temuan (finding)''' — satu celah yang bisa dijelaskan, dibuktikan, dan ditindaklanjuti.
* '''Baseline''' — potret keadaan sebelum diubah, dipakai sebagai pembanding.
* '''Permukaan serangan''' — jumlah pintu yang bisa dicoba: port, akun, berkas yang bisa diunduh.
* '''ACL''' — daftar izin tambahan di luar mode Unix. Bisa memberi akses tanpa mengubah angka <code>644</code>.
* '''Mode 640''' — pemilik boleh baca-tulis, grup boleh baca, pengguna lain tidak boleh apa-apa.
* '''Manifest hash''' — daftar sidik jari semua berkas, dipakai untuk mendeteksi perubahan.
* '''RTO terukur''' — waktu nyata dari layanan mati sampai melayani lagi, bukan angka di dokumen.
* '''Regresi''' — kerusakan baru yang muncul akibat perbaikan. Musuh utama audit.
* '''Least privilege''' — hak sekecil yang cukup, bukan hak penuh demi kemudahan.

== 🔧 Praktik: audit tiga pilar di satu layanan ==

Kita akan membangun satu layanan kecil, lalu memukulnya dengan tujuh pengujian. Setiap pengujian menghasilkan satu baris bukti dan satu skor.

Alat yang dipakai: <code>ss</code>, <code>find</code>, <code>stat</code>, <code>sha256sum</code>, <code>curl</code>, <code>getfacl</code>, dan <code>python3</code>. Semuanya tersedia di Debian dan Ubuntu.

=== 🔹 Langkah 0: siapkan lab dan snapshot ===

'''Ambil snapshot VM dulu.''' Setelah itu siapkan bahan uji: satu halaman, satu berkas nilai palsu, dan satu berkas konfigurasi yang sengaja ditinggalkan.

<syntaxhighlight lang="text">
sudo install -d -m 755 /srv/lab-audit/www/data /root/audit
printf '<h1>Nilai Kelas X</h1>\n' | sudo tee /srv/lab-audit/www/index.html
printf 'nama,nilai\nAni,80\nBudi,75\nCitra,90\n' | sudo tee /srv/lab-audit/www/data/nilai.csv
printf 'DB_USER=app_nilai\nDB_PASS=sandi-palsu-lab\n' | sudo tee /srv/lab-audit/www/config.bak
sudo chmod 644 /srv/lab-audit/www/index.html /srv/lab-audit/www/data/nilai.csv /srv/lab-audit/www/config.bak
</syntaxhighlight>

'''Nyalakan layanan sebagai pengguna rendah, bukan root.''' Ini penting: kalau layanan jalan sebagai root, semua uji izin akan menipu.

<syntaxhighlight lang="text">
sudo -u www-data python3 -m http.server 8080 --bind 127.0.0.1 --directory /srv/lab-audit/www >/dev/null 2>&1 &
sleep 1
curl -s -o /dev/null -w 'kode=%{http_code} waktu=%{time_total}\n' http://127.0.0.1:8080/data/nilai.csv
ps -o pid,user,stat,cmd -C python3
</syntaxhighlight>

Hasil yang diharapkan: <code>kode=200</code>, dan proses dimiliki <code>www-data</code>.

=== 🔹 Langkah 1: inventaris dan potret awal ===

Sebelum menilai, potret dulu. Simpan ke berkas bertanda waktu supaya bisa dibandingkan nanti.

<syntaxhighlight lang="text">
{
  date -Is
  ss -tlnp
  find /srv/lab-audit -printf '%M %u:%g %8s %p\n' | sort -k4
  curl -s -o /dev/null -w 'kode=%{http_code} waktu=%{time_total}\n' http://127.0.0.1:8080/data/nilai.csv
} | sudo tee /root/audit/baseline.txt
</syntaxhighlight>

Baca hasilnya baris per baris. Ada berapa port mendengarkan? Siapa pemilik berkas? Berapa ukurannya? Angka-angka ini yang nanti kamu bandingkan setelah perbaikan.

* 💡 '''Tips:''' Selalu simpan baseline dengan <code>date -Is</code> di baris pertama. Tanpa waktu, dua potret tidak bisa dibedakan mana yang lebih baru saat laporan dibaca orang lain.

=== 🔹 Langkah 2: uji kerahasiaan lewat izin berkas ===

'''Uji C-1.''' Coba baca berkas nilai sebagai pengguna paling rendah.

<syntaxhighlight lang="text">
sudo -u nobody cat /srv/lab-audit/www/data/nilai.csv
stat -c '%A %U:%G %n' /srv/lab-audit/www/data/nilai.csv
</syntaxhighlight>

Kalau isinya tercetak, kerahasiaan gagal. Mode <code>-rw-r--r--</code> berarti semua pengguna sistem boleh membaca.

'''Uji C-1b: cek ACL.''' Mode bisa terlihat rapi, tapi ACL menambah izin di belakangnya.

<syntaxhighlight lang="text">
sudo apt install -y acl
sudo setfacl -m u:nobody:r-- /srv/lab-audit/www/data/nilai.csv
stat -c '%A %n' /srv/lab-audit/www/data/nilai.csv
getfacl --omit-header /srv/lab-audit/www/data/nilai.csv
sudo -u nobody cat /srv/lab-audit/www/data/nilai.csv | head -2
</syntaxhighlight>

Perhatikan tanda <code>+</code> di akhir mode. Itu penanda ada ACL. Orang yang hanya membaca <code>ls -l</code> akan melewatkannya.

'''Bersihkan ACL''' setelah uji supaya temuan berikutnya tidak tercampur.

<syntaxhighlight lang="text">
sudo setfacl -x u:nobody /srv/lab-audit/www/data/nilai.csv
getfacl --omit-header /srv/lab-audit/www/data/nilai.csv
</syntaxhighlight>

=== 🔹 Langkah 3: uji kerahasiaan lewat pintu jaringan ===

Izin berkas benar tidak berarti layanan tidak membocorkan apa pun. Sekarang uji siapa yang bisa menjangkau port.

<syntaxhighlight lang="text">
pkill -f 'http.server 8080'; sleep 1
sudo -u www-data python3 -m http.server 8080 --bind 0.0.0.0 --directory /srv/lab-audit/www >/dev/null 2>&1 &
sleep 1
IP=$(hostname -I | awk '{print $1}')
curl -s -o /dev/null -w 'dari LAN: %{http_code}\n' --noproxy '*' "http://$IP:8080/data/nilai.csv"
ss -tlnp | grep 8080
</syntaxhighlight>

Hasil <code>200</code> dari alamat LAN berarti layanan terbuka untuk seluruh jaringan, bukan hanya mesin itu.

* ⚠️ '''Hati-hati:''' Tanpa <code>--noproxy '*'</code>, curl bisa mengirim permintaan ke proxy kantor dan kamu mengira port tertutup padahal terbuka. Ini kesalahan pengukuran yang paling sering terjadi saat audit dari laptop.

'''Kembalikan ke localhost''' dan buktikan perbedaannya.

<syntaxhighlight lang="text">
pkill -f 'http.server 8080'; sleep 1
sudo -u www-data python3 -m http.server 8080 --bind 127.0.0.1 --directory /srv/lab-audit/www >/dev/null 2>&1 &
sleep 1
curl -s -o /dev/null -w 'dari LAN: %{http_code}\n' --noproxy '*' "http://$IP:8080/data/nilai.csv"
curl -s -o /dev/null -w 'dari lokal: %{http_code}\n' http://127.0.0.1:8080/data/nilai.csv
</syntaxhighlight>

Dari LAN hasilnya <code>000</code> (tidak bisa connect), dari lokal <code>200</code>. Satu argumen mengubah luas permukaan serangan secara nyata.

=== 🔹 Langkah 4: uji kerahasiaan lewat berkas sisa ===

Berkas cadangan, berkas <code>.bak</code>, dan berkas konfigurasi adalah kebocoran paling umum di server sekolah.

<syntaxhighlight lang="text">
curl -s -o /dev/null -w 'config.bak: %{http_code}\n' http://127.0.0.1:8080/config.bak
curl -s http://127.0.0.1:8080/config.bak
</syntaxhighlight>

Kalau hasilnya <code>200</code> dan isinya menampilkan sandi, itu temuan kerahasiaan dengan tingkat keparahan tinggi. Bukan karena sandinya asli, tapi karena pola kebiasaannya berbahaya.

* 🧪 '''Uji cepat:''' <code>curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080/config.bak</code> menghasilkan 200 berarti berkas bisa diunduh tanpa login. Ganti namanya jadi <code>config.txt</code> untuk membuktikan server memang menyajikan berkas apa pun di foldernya.

=== 🔹 Langkah 5: uji integritas dengan manifest ===

'''Uji I-1.''' Buat sidik jari semua berkas, simpan di luar folder web, lalu ubah satu nilai.

<syntaxhighlight lang="text">
cd /srv/lab-audit
sudo find www -type f -exec sha256sum {} + | sudo tee /root/audit/manifest.sha256
sudo sed -i 's/Budi,75/Budi,95/' www/data/nilai.csv
sudo sha256sum -c /root/audit/manifest.sha256; echo "kode keluar=$?"
</syntaxhighlight>

Hasilnya <code>FAILED</code> dengan kode keluar 1. Perubahan terdeteksi.

'''Uji I-1b: perubahan yang menyamar.''' Sekarang ubah isi tanpa mengubah ukuran, lalu kembalikan mtime.

<syntaxhighlight lang="text">
sudo sed -i 's/Budi,95/Budi,45/' /srv/lab-audit/www/data/nilai.csv
sudo touch -r /root/audit/baseline.txt /srv/lab-audit/www/data/nilai.csv
sudo find /srv/lab-audit/www -type f -newer /root/audit/baseline.txt
sudo sha256sum -c /root/audit/manifest.sha256; echo "kode keluar=$?"
</syntaxhighlight>

<code>find -newer</code> tidak menemukan apa pun, padahal isinya sudah berubah dari 75 menjadi 45. Hanya hash yang menangkapnya.

* 📊 '''Angka penting:''' <code>Budi,75</code> dan <code>Budi,45</code> sama-sama 7 byte. Pemeriksaan yang hanya membandingkan ukuran dan waktu akan melaporkan "tidak ada perubahan" dengan yakin.

=== 🔹 Langkah 6: uji integritas dengan jejak waktu ===

Hash memberi tahu ada perubahan, tapi tidak memberi tahu siapa pelakunya. Untuk itu kamu butuh jejak.

<syntaxhighlight lang="text">
stat -c 'mtime=%y%nctime=%z' /srv/lab-audit/www/data/nilai.csv
sudo touch -d '2020-01-01 00:00' /srv/lab-audit/www/data/nilai.csv
stat -c 'mtime=%y%nctime=%z' /srv/lab-audit/www/data/nilai.csv
</syntaxhighlight>

Mtime bisa diubah ke tahun 2020. Ctime tidak bisa: setiap perubahan metadata memperbarui ctime, dan tidak ada perintah untuk memundurkannya.

Artinya, ctime hanya membuktikan "pernah terjadi sesuatu", bukan "siapa yang melakukan". Di sistem tanpa audit log, pelaku tetap tidak diketahui.

<syntaxhighlight lang="text">
command -v auditctl || echo 'auditd tidak terpasang: tidak ada jejak pelaku'
sudo grep -c '' /var/log/auth.log 2>/dev/null || echo 'auth.log tidak terbaca'
</syntaxhighlight>

* 💡 '''Tips:''' Tulis di lembar temuan apa adanya: "perubahan terdeteksi, pelaku tidak teridentifikasi". Itu temuan yang jujur, dan langsung menunjukkan perbaikan berikutnya, yaitu memasang audit log dan mengirimnya ke mesin lain.

=== 🔹 Langkah 7: uji ketersediaan, hidup belum tentu melayani ===

Panel monitoring biasanya hanya bertanya "prosesnya ada?". Pertanyaan yang benar: "apakah menjawab?".

<syntaxhighlight lang="text">
for i in 1 2 3; do
  curl -s -o /dev/null -w 'kode=%{http_code} waktu=%{time_total}\n' --max-time 3 http://127.0.0.1:8080/
done
PID=$(pgrep -f 'http.server 8080' | head -1)
sudo kill -STOP "$PID"
ps -o pid,stat,cmd -p "$PID"
curl -s -o /dev/null -w 'kode=%{http_code}\n' --max-time 3 http://127.0.0.1:8080/
sudo kill -CONT "$PID"
</syntaxhighlight>

Proses masih ada, statusnya <code>T</code> (stopped), tapi permintaan berakhir <code>000</code> setelah 3 detik. Inilah bentuk "layanan hidup tapi mati" yang paling sering lolos dari monitoring.

* 🔥 '''Kasus nyata:''' Pada sebuah ujian sekolah, panel monitoring menampilkan server "aktif" selama sebelas menit saat siswa tidak bisa menyimpan jawaban. Prosesnya memang hidup, tapi berhenti merespons karena disk penuh dan penulisan menggantung. Guru menyimpulkan jaringan yang salah, teknisi me-restart switch, dan waktu ujian habis. Pemeriksaan yang benar cuma satu: <code>curl</code> ke halaman ujian, bukan melihat status proses.

=== 🔹 Langkah 8: ukur RTO layanan, bukan RTO arsip ===

RTO yang ditulis di dokumen hampir selalu lebih cepat dari kenyataan, karena yang dihitung hanya "ekstrak arsip", bukan "sampai melayani lagi".

<syntaxhighlight lang="text">
pkill -f 'http.server 8080'; sleep 1
sudo tar -czf /root/audit/www.tgz -C /srv/lab-audit www
sudo rm -rf /srv/lab-audit/www
MULAI=$(date +%s%N)
sudo tar -xzf /root/audit/www.tgz -C /srv/lab-audit
sudo -u www-data python3 -m http.server 8080 --bind 127.0.0.1 --directory /srv/lab-audit/www >/dev/null 2>&1 &
until curl -s -o /dev/null --max-time 1 http://127.0.0.1:8080/; do sleep 0.2; done
SELESAI=$(date +%s%N)
echo "RTO layanan = $(( (SELESAI - MULAI) / 1000000 )) ms"
</syntaxhighlight>

Catat angkanya, jangan dibulatkan ke "cepat". Di lab ini nilainya kecil karena datanya kecil. Di server sekolah dengan basis data 2 GB, angka yang sama bisa berjam-jam.

'''Uji A-1: apakah ada yang tahu saat layanan mati?''' Matikan lagi dan lihat apakah ada alarm, log, atau chat yang berbunyi.

<syntaxhighlight lang="text">
pkill -f 'http.server 8080'; sleep 1
curl -s -o /dev/null -w 'kode=%{http_code}\n' --max-time 2 http://127.0.0.1:8080/
journalctl --since '-2 min' | tail -5
</syntaxhighlight>

Kalau tidak ada satu pun baris yang mencatat kematian layanan, skor ketersediaan bukan 2, tapi 0 untuk sisi deteksi. Layanan bisa pulih, tapi tidak ada yang tahu kalau sedang mati.

=== 🔹 Langkah 9: perbaiki tanpa merusak pilar lain ===

Ini bagian yang paling sering dilupakan. Perbaikan kerahasiaan yang salah akan mematikan ketersediaan.

'''Perbaikan naif.''' Kunci berkas nilai untuk semua orang kecuali root.

<syntaxhighlight lang="text">
sudo -u www-data python3 -m http.server 8080 --bind 127.0.0.1 --directory /srv/lab-audit/www >/dev/null 2>&1 &
sleep 1
sudo chmod 600 /srv/lab-audit/www/data/nilai.csv
stat -c '%A %U:%G %n' /srv/lab-audit/www/data/nilai.csv
curl -s -o /dev/null -w 'nilai.csv: %{http_code}\n' http://127.0.0.1:8080/data/nilai.csv
</syntaxhighlight>

Hasilnya <code>403</code>. Kerahasiaan naik, ketersediaan jatuh. Aplikasi tidak bisa membaca data yang dilindunginya.

'''Perbaikan benar.''' Beri hak baca hanya kepada grup yang memang menjalankan layanan.

<syntaxhighlight lang="text">
sudo chown root:www-data /srv/lab-audit/www/data/nilai.csv
sudo chmod 640 /srv/lab-audit/www/data/nilai.csv
sudo chmod 750 /srv/lab-audit/www/data
curl -s -o /dev/null -w 'nilai.csv: %{http_code}\n' http://127.0.0.1:8080/data/nilai.csv
sudo -u nobody cat /srv/lab-audit/www/data/nilai.csv
</syntaxhighlight>

Sekarang <code>200</code> dari layanan, dan <code>Permission denied</code> dari pengguna lain. Dua pilar membaik tanpa saling merusak.

'''Pindahkan berkas sisa keluar dari folder web.''' Mengunci berkas bocor tidak sebaik menghilangkannya dari jangkauan.

<syntaxhighlight lang="text">
sudo install -d -m 750 /srv/lab-audit/rahasia
sudo mv /srv/lab-audit/www/config.bak /srv/lab-audit/rahasia/config.bak
sudo chmod 640 /srv/lab-audit/rahasia/config.bak
curl -s -o /dev/null -w 'config.bak: %{http_code}\n' http://127.0.0.1:8080/config.bak
</syntaxhighlight>

Hasil <code>404</code> adalah hasil yang benar. Berkasnya masih ada untuk keperluan operasional, tapi tidak lagi bisa diunduh.

=== 🔹 Langkah 10: isi lembar temuan dan tentukan prioritas ===

Lembar temuan adalah dokumen kerja, bukan karya sastra. Empat kolom cukup.

{| class="wikitable"
! ID !! Kontrol yang diuji !! Bukti !! Skor
|-
| C-1 || izin berkas nilai || <code>nobody</code> bisa membaca, mode 644 || 0
|-
| C-2 || batas jaringan || bind 0.0.0.0, 200 dari alamat LAN || 0
|-
| C-3 || berkas sisa di web || <code>/config.bak</code> 200, berisi sandi || 0
|-
| I-1 || manifest hash || perubahan 75 ke 45 terdeteksi FAILED || 1
|-
| I-2 || jejak pelaku || ctime berubah, tidak ada audit log || 0
|-
| A-1 || deteksi gangguan || proses STOP, tidak ada alarm || 0
|-
| A-2 || RTO terukur || pulih dan melayani dalam hitungan detik || 2
|}

Perhatikan I-1: kontrolnya ada, tapi manifest disimpan di mesin yang sama. Kalau penyerang bisa mengubah data, dia bisa mengubah manifest juga. Skor 1, bukan 2.

'''Urutkan prioritas''' dengan dampak dikali peluang. Jangan mengurutkan dari yang paling mudah diperbaiki.

{| class="wikitable"
! Temuan !! Dampak !! Peluang !! Prioritas
|-
| C-3 berkas sisa || 3 || 3 || 9, kerjakan hari ini
|-
| C-1 izin berkas || 3 || 2 || 6, hari ini
|-
| C-2 bind terbuka || 3 || 2 || 6, hari ini
|-
| A-1 tanpa alarm || 3 || 2 || 6, minggu ini
|-
| I-2 tanpa jejak || 2 || 2 || 4, bulan ini
|-
| I-1 manifest lokal || 2 || 1 || 2, bulan ini
|}

=== 🔹 Langkah 11: uji ulang dan cek regresi ===

Setelah semua perbaikan, jalankan ulang uji yang sama persis. Bukan uji baru, bukan uji yang lebih longgar.

{| class="wikitable"
! Uji !! Sebelum !! Sesudah !! Pilar aman
|-
| Baca sebagai nobody || berhasil || ditolak || kerahasiaan
|-
| Akses dari LAN || 200 || 000 || kerahasiaan
|-
| Unduh config.bak || 200 || 404 || kerahasiaan
|-
| Hash setelah diubah || FAILED || FAILED || integritas
|-
| Halaman dari layanan || 200 || 200 || ketersediaan
|-
| Deteksi saat mati || tidak ada || belum diuji || deteksi
|}

Baris terakhir sengaja dibiarkan. Menulis "belum diuji" lebih berharga daripada menulis "aman" tanpa bukti.

* 🧪 '''Uji cepat:''' Bandingkan baseline lama dengan potret baru, lalu hitung bedanya. <code>sudo diff /root/audit/baseline.txt /root/audit/akhir.txt</code>. Kalau tidak ada satu baris pun yang berubah, kamu belum memperbaiki apa pun.

=== 🔹 Langkah 12: bersih-bersih ===

Lab yang ditinggalkan menjadi temuan baru di kemudian hari.

<syntaxhighlight lang="text">
pkill -f 'http.server 8080'
sudo rm -rf /srv/lab-audit /root/audit
sudo ss -tlnp | grep 8080 || echo 'port 8080 bersih'
</syntaxhighlight>

Kalau kamu memakai VM latihan, kembalikan ke snapshot. Kalau memakai mesin nyata, pastikan tidak ada berkas uji yang tertinggal di folder web.

== 🏭 Dipakai di dunia kerja ==

* '''Sekolah dan kampus:''' audit dilakukan sebelum ujian berbasis komputer dan sebelum data naik kelas. Yang diperiksa bukan hanya "server hidup", tapi apakah nilai bisa dibaca pihak yang tidak berhak dan apakah ada bukti kalau nilainya diubah.
* '''Kantor dan UMKM:''' pemilik biasanya meminta satu hal sederhana: bukti bahwa kasir tidak bisa melihat harga modal. Jawabannya bukan "sudah dikunci", tapi tangkapan layar izin, keluaran perintah, dan hasil uji ulang.
* '''Klinik dan rumah sakit:''' rekam medis menuntut kerahasiaan sekaligus ketersediaan. Audit di sini selalu berpasangan: siapa boleh membuka, dan berapa menit layanan boleh mati sebelum pasien terlantar.
* '''Hosting dan penyedia layanan:''' audit adalah dokumen kontrak. RTO dan RPO tertulis di SLA, dan pelanggan akan meminta bukti saat gangguan, bukan janji saat penandatanganan.
* '''Industri dan manufaktur:''' integritas data sensor menentukan kualitas produk. Perubahan kecil yang tidak terdeteksi bisa membuat satu batch produksi salah spesifikasi tanpa ada yang sadar.
* '''Freelancer dan konsultan IT:''' laporan audit yang rapi adalah produknya. Klien membayar untuk temuan yang bisa diulang, bukan opini yang panjang.

== ✅ Verifikasi ==

{| class="wikitable"
! Yang diperiksa !! Perintah !! Hasil yang benar
|-
| Layanan menjawab || <code>curl -o /dev/null -w '%{http_code}'</code> || <code>200</code>
|-
| Layanan mati || setelah <code>pkill</code> || <code>000</code>
|-
| Port terbuka || <code>sudo ss -tlnp</code> || hanya port yang perlu
|-
| Izin berkas || <code>stat -c '%A %U:%G'</code> || <code>-rw-r----- root www-data</code>
|-
| ACL tersembunyi || <code>getfacl --omit-header</code> || hanya izin yang kamu buat
|-
| Baca oleh orang lain || <code>sudo -u nobody cat</code> || <code>Permission denied</code>
|-
| Berkas sisa || <code>curl -o /dev/null -w '%{http_code}' .../config.bak</code> || <code>404</code>
|-
| Hash utuh || <code>sha256sum -c</code> || <code>OK</code>, kode keluar 0
|-
| Hash berubah || setelah <code>sed -i</code> || <code>FAILED</code>, kode keluar 1
|-
| RTO terukur || <code>date +%s%N</code> sebelum dan sesudah || angka milidetik tercatat
|}

== ⚠️ Kesalahan umum & troubleshooting ==

{| class="wikitable"
! Gejala !! Arti sebenarnya !! Cek cepat
|-
| <code>sudo -u nobody</code> menolak dengan "account is currently not available" || shell akun <code>nobody</code> adalah nologin || pakai <code>sudo -u www-data</code> atau <code>runuser -u nobody -- cat</code>
|-
| <code>curl</code> balas 403 padahal mode 644 || layanan jalan sebagai pengguna lain, atau folder induk tanpa bit x || <code>namei -l /path/berkas</code>
|-
| <code>curl</code> 200 di lokal, 000 dari HP || layanan bind ke 127.0.0.1 || <code>ss -tlnp | grep 8080</code>
|-
| <code>curl</code> 000 padahal port listen || proses berhenti (SIGSTOP), firewall, atau proxy lingkungan || <code>ps -o stat</code>, lalu <code>--noproxy '*'</code>
|-
| Kolom Process di <code>ss</code> kosong || soket milik pengguna lain || jalankan dengan <code>sudo</code>
|-
| <code>getfacl: command not found</code> || paket <code>acl</code> belum ada || <code>sudo apt install -y acl</code>
|-
| Hash selalu OK padahal isi berubah || manifest ikut berubah atau path relatif salah || verifikasi dari folder yang sama, simpan manifest di luar mesin
|-
| <code>kill %1</code> bilang no such job || job hanya hidup di sesi shell yang sama || pakai <code>pkill -f 'http.server 8080'</code>
|-
| Port 8080 sudah dipakai || ada proses lain, sering dari lab sebelumnya || <code>ss -tlnp | grep 8080</code> lalu <code>pkill</code>
|-
| RTO terbaca 0 ms || <code>until curl</code> dijawab proses lama yang belum mati || matikan dulu, pastikan <code>000</code>, baru ukur
|}

Tiga mitos yang perlu dipensiunkan:

* "Sudah HTTPS berarti kerahasiaan selesai" — HTTPS melindungi perjalanan data, bukan berkas yang diletakkan di folder publik.
* "Sudah ada hash berarti integritas selesai" — hash tanpa penyimpanan terpisah hanya mendeteksi perubahan yang tidak disengaja.
* "Sudah ada monitoring berarti ketersediaan selesai" — monitoring proses tidak sama dengan monitoring jawaban.

== 🔐 Catatan keamanan & etika ==

* Audit hanya pada aset milikmu atau yang ada izin tertulis. Memeriksa server sekolah tanpa penugasan bisa melanggar aturan internal dan UU ITE.
* Jangan memindai atau menguji jaringan orang lain, walaupun hanya satu perintah. Izin lisan dari teman bukan izin dari pemilik.
* Data nilai, rekam medis, dan data pelanggan adalah data pribadi. Sejak 17 Oktober 2024, UU No. 27 Tahun 2022 berlaku penuh.
* Jangan menempel data asli di laporan. Ganti nama, potong nomor, atau gunakan data palsu seperti di lab ini.
* Berkas konfigurasi berisi sandi tidak boleh berada di folder web, sekalipun bernama <code>.bak</code> atau <code>.old</code>.
* Laporan audit adalah peta kelemahan. Simpan dengan izin terbatas, jangan bagikan ke grup umum, dan jangan diunggah ke layanan publik.
* Ambil snapshot sebelum menguji, dan jangan menguji di jam sibuk. Uji <code>kill -STOP</code> pada layanan produksi berarti layanan benar-benar berhenti.
* Kalau menemukan celah di sistem orang lain, laporkan lewat jalur resmi. Jangan gunakan temuan untuk membuktikan diri di media sosial.
* Hapus lab setelah selesai. Layanan uji yang lupa dimatikan adalah pintu baru yang tidak tercatat di inventaris siapa pun.

== 📌 Kesimpulan ==

Audit bukan pekerjaan mencari kesalahan orang, tapi pekerjaan mengganti "kayaknya aman" dengan bukti yang bisa diulang.

Tiga hal yang paling menentukan hasilnya: uji dengan akun terendah, jangan percaya waktu berkas sebagai bukti integritas, dan ukur ketersediaan dari jawaban layanan bukan dari status proses.

Dan satu kebiasaan yang membedakan auditor pemula dari yang dipercaya: setelah memperbaiki, dia mengulang uji yang sama dan memeriksa apakah pilar lain ikut rusak.

Langkah berikutnya: ambil satu layanan nyata di labmu, isi lembar temuan empat kolom, lalu perbaiki satu baris dengan skor tertinggi. Setelah itu lanjut ke [[Linux : Praktikum Hardening SSH dan Audit Konfigurasi]] untuk memperkuat pintu masuk, atau [[Linux : Praktikum Uji Restore dan Verifikasi Arsip Backup]] untuk membuktikan sisi ketersediaan.

== 🔗 Materi terkait ==

* [[Cyber Security : CIA Triad dan Dasar Ancaman Siber]] — kerangka konsep tiga pilar yang dipakai lab ini.
* [[Linux : Manajemen User, Group, dan sudo]] — dasar izin berkas dan grup yang membuat uji C-1 masuk akal.
* [[Linux : Praktikum Audit Akun, Group, dan Hak sudo]] — audit sisi identitas, lanjutan alami setelah audit layanan.
* [[Linux : SSH Hardening Lanjutan (Lima Lapis Kunci Akses)]] — mengurangi pintu masuk yang bisa diuji.
* [[Linux : Praktikum Hardening SSH dan Audit Konfigurasi]] — contoh lembar temuan pada konfigurasi nyata.
* [[Linux : Praktikum Uji Restore dan Verifikasi Arsip Backup]] — membuktikan ketersediaan lewat pemulihan.
* [[Linux : Log dan journalctl untuk Troubleshooting]] — membangun jejak yang dibutuhkan uji I-2.
* [[Linux : Monitoring Server Dasar (htop, netdata)]] — mendeteksi gangguan sebelum pengguna melapor.
* [[Cyber Security: Belajar Nmap untuk Audit Jaringan Legal]] — memetakan permukaan serangan secara legal.

== 📚 Referensi ==

# [https://csrc.nist.gov/pubs/sp/800/53/a/r5/final NIST SP 800-53A Rev. 5 — Assessing Security and Privacy Controls] — kerangka penilaian kontrol dengan metode examine, interview, dan test.
# [https://csrc.nist.gov/glossary/term/confidentiality NIST CSRC Glossary — confidentiality] — definisi resmi kerahasiaan.
# [https://csrc.nist.gov/glossary/term/integrity NIST CSRC Glossary — integrity] — definisi integritas termasuk non-repudiation.
# [https://csrc.nist.gov/glossary/term/availability NIST CSRC Glossary — availability] — definisi ketersediaan.
# [https://manpages.debian.org/bookworm/iproute2/ss.8.en.html ss(8) — Debian bookworm] — opsi <code>-t</code>, <code>-l</code>, <code>-n</code>, dan <code>-p</code> untuk membaca soket.
# [https://curl.se/docs/manpage.html curl — write-out variables] — arti <code>%{http_code}</code> dan <code>%{time_total}</code>, serta opsi <code>--max-time</code> dan <code>--noproxy</code>.
# [https://manpages.debian.org/bookworm/coreutils/sha256sum.1.en.html sha256sum(1) — Debian bookworm] — kode keluar 0 saat cocok, 1 saat ada ketidakcocokan.
# [https://manpages.debian.org/bookworm/coreutils/stat.1.en.html stat(1) — Debian bookworm] — arti <code>%y</code> (mtime) dan <code>%z</code> (ctime).
# [https://manpages.debian.org/bookworm/acl/getfacl.1.en.html getfacl(1) — Debian bookworm] — membaca ACL di luar mode Unix.
# [https://docs.python.org/3/library/http.server.html Python — http.server] — port bawaan 8000, opsi <code>--bind</code> dan <code>--directory</code>.
# [https://peraturan.bpk.go.id/Details/229798/uu-no-27-tahun-2022 UU No. 27 Tahun 2022 tentang Pelindungan Data Pribadi] — dasar hukum perlindungan data pribadi di Indonesia.

[[Category:TKJ]]
[[Category:Cyber Security]]
[[Category:Jaringan]]