Linux : Praktikum Audit Akun, Group, dan Hak sudo

Kalau audit dimulai dengan menghapus sesuatu, kamu sedang menebak. Audit yang benar dimulai dengan mencatat, lalu membuktikan. Di server, "kayaknya aman" bukan jawaban — yang menjawab adalah daftar nama, nomor UID, dan baris izin yang bisa kamu tunjuk.

Artikel ini adalah lanjutan langsung dari Linux : Manajemen User, Group, dan sudo. Pagi tadi kamu belajar membuat identitas dan memberi kewenangan. Sore ini kamu belajar memeriksa server yang dibuat orang lain, menemukan sisa kewenangan yang tidak seharusnya ada, dan membuktikannya dengan perintah.

🎯 Tujuan

Setelah mengikuti praktikum ini, kamu bisa:

• Menjalankan audit akses lima lapis pada satu server Debian, dari "siapa bisa masuk" sampai "siapa meninggalkan jejak".
• Membuktikan temuan dengan perintah yang bisa diulang orang lain, bukan dengan dugaan.
• Membedakan akun yang password-nya terkunci dari akun yang benar-benar tidak bisa dipakai.
• Menemukan jalur naik hak yang tidak lewat sudoers, misalnya group docker atau file SUID.
• Memperbaiki temuan tanpa mengunci diri sendiri di luar server.

💡 Tips: siapkan satu VM lab atau snapshot sebelum mulai. Praktikum ini sengaja menanam akun UID 0 kedua dan file SUID. Jangan dijalankan di server produksi.

📍 Konteks nyata

Bayangkan kamu baru masuk kerja di sebuah SMK. Server ujian diwarisi dari guru yang pindah tugas. Katanya, "sudah aman, tinggal pakai". Kamu tidak tahu siapa saja yang punya kunci.

Di rumah kos, masalah serah terima bukan gagang pintu yang rusak — masalahnya kunci lama yang masih dipegang mantan penghuni. Mengganti gagang pintu tidak menolong kalau salinan kuncinya masih beredar. Yang perlu kamu lakukan adalah menghitung kunci: siapa punya, pintu mana yang dibuka, dan kapan terakhir dipakai.

🔥 Kasus nyata: sebuah SMK mewarisi server CBT dari guru yang pindah. Akun operator masih aktif dengan password yang sama sejak dua tahun lalu.

Akun itu dipakai bergantian oleh empat orang. Ketika nilai tiga kelas berubah tanpa penjelasan, tidak ada satu pun nama di log yang bisa ditunjuk — semua perbuatan tercatat atas nama operator.

Panitia menghabiskan dua hari mencurigai siswa. Masalah sebenarnya ada di akun bersama yang tidak pernah diaudit saat serah terima.

🧠 Konsep singkat

🔹 Lima lapis audit

Audit akses bukan satu perintah ajaib. Ada lima lapis yang harus diperiksa berurutan, karena lapis bawahnya tidak akan terlihat kalau lapis atas belum beres.

Lapis	Pertanyaan	Bukti utama
1. Pintu masuk	Siapa yang bisa login, dengan cara apa?	getent passwd, authorized_keys, sshd -T
2. Naik hak	Siapa yang bisa jadi root?	awk '$3==0', group sudo, SUID
3. Kewenangan	Perintah apa yang boleh dijalankan?	sudo -l -U, isi /etc/sudoers.d
4. Data	File siapa yang terbuka untuk siapa?	find -nouser, -perm -4000, -perm -0002
5. Jejak	Siapa benar-benar melakukan apa?	last, journalctl _COMM=sudo

📊 Angka penting: di Debian, UID 1–999 dipakai akun sistem, UID 1000 ke atas untuk manusia, dan 65534 untuk nobody. Batas ini dibaca dari /etc/login.defs (UID_MIN), bukan ditulis di kepala kita.

🔹 Audit itu soal pertanggungjawaban

Pertanyaan inti audit bukan "apakah server ini aman", tapi "kalau ada yang salah, bisakah kita tahu siapa". Dua akun dengan UID sama membuat pertanyaan itu tidak bisa dijawab.

Kernel tidak peduli nama. Kalau budi dan operator sama-sama UID 1001, semua file dan proses tercatat milik angka 1001. Log akan menampilkan nama yang muncul lebih dulu di /etc/passwd, dan bisa jadi bukan orang yang benar-benar bekerja.

🔹 Tiga status akun yang sering tertukar

Banyak admin menganggap passwd -l sudah "mematikan akun". Dokumentasi resmi passwd(1) menyebut sebaliknya.

Status	Arti	Login password	Login kunci SSH
P	password bisa dipakai	bisa	bisa
L	password dikunci dengan awalan !	gagal	masih bisa
NP	tidak ada password sama sekali	gagal	masih bisa

⚠️ Hati-hati: passwd -l hanya mengunci password, bukan akun. Selama ~/.ssh/authorized_keys masih berisi kunci, orang itu tetap bisa masuk tanpa pernah menyentuh password. Untuk benar-benar menutup akun, dokumentasi passwd(1) menyarankan usermod --expiredate 1.

🔹 "Punya sudo" bukan satu status

Ada empat jalan berbeda menuju root, dan audit yang hanya membaca /etc/sudoers akan buta pada tiga di antaranya.

• Anggota group sudo — di Debian, group ini sudah punya baris izin di sudoers, jadi menambah anggota sama dengan memberi root penuh.
• Baris izin di /etc/sudoers.d — bisa sempit (systemctl restart nginx) atau sangat luas (ALL).
• Group lain yang setara root — docker, disk, lxd. Tidak muncul di sudo -l, tapi efeknya sama.
• File SUID milik root — program apa pun yang berjalan dengan hak pemilik file, bukan hak pemanggilnya.

💡 Tips: saat audit, tulis keempat jalur ini di kertas. Setiap temuan harus masuk ke salah satunya, supaya tidak ada yang terlewat.

🧩 Istilah penting

• UID — angka identitas pemilik. Nama hanya label tampilan; kernel memakai angka.
• GID — angka identitas group. Satu user punya satu GID primer dan boleh punya banyak GID tambahan.
• /etc/shadow — tempat hash password. Hanya root yang boleh membaca; kalau bocor, hash bisa dipecahkan di luar server.
• PAM — lapisan yang memutuskan boleh-tidaknya login. Banyak aturan "akun ditolak" sebenarnya bekerja di sini, bukan di file password.
• Real vs effective UID — identitas asli pemanggil dan identitas yang dipakai saat menjalankan program. SUID mengubah yang kedua.
• File yatim — file yang pemiliknya sudah tidak ada di /etc/passwd. Tampil sebagai angka di ls -n.
• SUID — bit izin yang membuat program berjalan dengan hak pemilik file, biasanya root.
• Sticky bit — pengaman pada folder 1777: orang boleh menulis, tapi hanya boleh menghapus file miliknya sendiri.
• Drop-in sudoers — file tambahan di /etc/sudoers.d/ yang dibaca lewat #includedir.
• Timestamp cache — sudo mengingat password yang sudah dimasukkan, bawaannya 15 menit per terminal.

🔧 Praktik: audit server warisan

Lab ini memakai satu VM Debian 12. Kamu akan menanam enam masalah seperti yang sering ditemukan di server serah terima, lalu menemukannya satu per satu.

🔹 Langkah 0: siapkan bahan

Jalankan sebagai root atau lewat sudo. Skrip ini membuat akun, kunci, folder, dan file yang akan kamu audit.

# akun untuk latihan
groupadd -f lab-audit
useradd -m -s /bin/bash -G lab-audit siswa1
useradd -m -s /bin/bash siswa2
useradd -m -s /bin/bash -G sudo siswa3

# akun "warisan": password dikunci, tapi kunci SSH masih ada
useradd -m -s /bin/bash teknisi
echo 'teknisi:Temp1234' | chpasswd
passwd -l teknisi
install -d -m 700 -o teknisi -g teknisi /home/teknisi/.ssh
echo 'ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILab latihan' > /home/teknisi/.ssh/authorized_keys
chown teknisi:teknisi /home/teknisi/.ssh/authorized_keys
chmod 600 /home/teknisi/.ssh/authorized_keys

# UID 0 kedua, dan UID kembar
useradd -m -s /bin/bash -u 0 tukang
useradd -m -o -u 1001 -s /bin/bash kembar

# file yatim milik UID yang tidak ada
mkdir -p /srv/arsip-nilai
echo 'nilai-2023' > /srv/arsip-nilai/nilai-2023.csv
chown -R 4242:4242 /srv/arsip-nilai

# folder terbuka tanpa sticky bit
mkdir -p /srv/publik
chmod 0777 /srv/publik

# file SUID buatan sendiri
install -m 4755 /usr/bin/id /usr/local/bin/id-baru

⚠️ Hati-hati: opsi -o pada useradd artinya "boleh memakai UID yang sudah dipakai". Tanpa -o, useradd menolak UID kembar. Di server sungguhan, UID kembar biasanya muncul dari restore /etc/passwd lama atau dari alat provisioning yang salah.

🔹 Langkah 1: potret keadaan awal

Sebelum menyentuh apa pun, simpan bukti. Audit yang tidak punya pembanding tidak bisa membuktikan perbaikan.

install -d -m 700 /root/audit
getent passwd | sort > /root/audit/passwd.before
getent group  | sort > /root/audit/group.before
cp /etc/passwd /root/audit/passwd.raw
cp /etc/group  /root/audit/group.raw
cp /etc/sudoers /root/audit/sudoers.raw
visudo -c

🧪 Uji cepat: visudo -c harus menjawab parsed OK. Kalau tidak, auditmu dimulai dari server yang sudah rusak dan setiap perubahan berikutnya berisiko.

🔹 Langkah 2: pisahkan akun manusia dan sistem

Daftar getent passwd panjang dan berisik. Yang kamu cari hanya akun yang bisa dipakai login.

# batas UID yang dipakai sistem ini
grep -E '^(UID_MIN|UID_MAX)' /etc/login.defs

# akun manusia: UID di atas UID_MIN, punya shell login
awk -F: '$3>=1000 && $3<65534 && $7 !~ /(nologin|false)$/ {print $1, $3, $7}' /etc/passwd

# akun yang punya shell login meskipun UID-nya sistem
awk -F: '$3<1000 && $7 !~ /(nologin|false)$/ {print $1, $3, $7}' /etc/passwd

Perintah kedua adalah yang sering dilupakan. Akun sistem dengan shell /bin/bash adalah pintu yang tidak perlu ada, dan biasanya sisa dari pemasangan aplikasi lama.

🔹 Langkah 3: cari UID 0 dan UID kembar

# siapa saja yang setara root
awk -F: '$3==0 {print $1}' /etc/passwd

# UID yang dipakai lebih dari satu nama
awk -F: '{print $3}' /etc/passwd | sort -n | uniq -d

# tampilkan nama-nama yang berbagi UID itu
awk -F: '{print $3}' /etc/passwd | sort -n | uniq -d | while read u; do
  echo "UID $u:"; awk -F: -v u="$u" '$3==u {print "  " $1}' /etc/passwd
done

Hasil yang diharapkan di lab: tukang muncul sebagai UID 0, dan siswa1 berbagi UID dengan kembar.

📊 Angka penting: satu akun UID 0 tambahan berarti satu password tambahan yang bisa membuka seluruh server. Banyak panduan hardening menyebut ini sebagai temuan tingkat tertinggi, karena tidak terlihat dari sudo -l sama sekali.

🔹 Langkah 4: uji status akun dan jalur masuk kedua

Jangan percaya status. Buktikan dengan mencoba.

# status password semua akun manusia
passwd -S -a | awk '$2!="P"'

# apakah ada kunci SSH yang menempel di home
find /home -maxdepth 3 -name authorized_keys -printf '%u %p\n' 2>/dev/null

# kebijakan autentikasi yang benar-benar dipakai sshd
sshd -T | grep -E '^(pubkeyauthentication|passwordauthentication|permitrootlogin|allowusers)'

Di lab, teknisi tampil L (locked), tapi tetap punya authorized_keys. Artinya: password mati, pintu tetap terbuka.

🔹 Langkah 5: petakan group sensitif

Keanggotaan group adalah kewenangan yang paling sering luput diaudit, karena tidak muncul di mana pun saat user mengetik sudo.

Group	Aksesnya	Kenapa berbahaya
sudo	baris izin ALL di sudoers	setara root penuh
docker	mengelola container	bisa mount / ke container dan jadi root
disk	membaca blok device mentah	bisa membaca semua file tanpa izin
adm	membaca log sistem	melihat aktivitas semua orang

for g in sudo adm disk docker lxd shadow; do
  getent group "$g"
done

# siapa anggota group sudo, termasuk lewat group lain
getent group sudo

🔹 Langkah 6: baca kewenangan efektif sudo

Membaca file sudoers mentah tidak cukup. Yang penting adalah hasil akhir yang dilihat sudo setelah semua file digabung.

# periksa sintaks seluruh konfigurasi
visudo -c

# tampilkan baris aktif di drop-in
grep -Rhs '^[^#]' /etc/sudoers.d/ | sort

# kewenangan efektif seorang user (harus root)
sudo -l -U siswa1
sudo -ll -U siswa1

Opsi -U hanya boleh dipakai root dan hanya bekerja bersama -l atau -v. Inilah cara audit yang benar: bertanya pada sudo, bukan menebak dari file.

💡 Tips: sudo -ll memberi format panjang yang menyebut nama file aturan. Ini menyelamatkan waktu saat harus menjelaskan temuan ke orang lain.

🔹 Langkah 7: cari file tak bertuan dan file terbuka

# file yatim: pemilik atau group-nya tidak ada di passwd/group
find / -xdev \( -nouser -o -nogroup \) -print 2>/dev/null

# file dengan bit SUID
find / -xdev -perm -4000 -type f 2>/dev/null

# folder yang bisa ditulisi siapa pun tanpa sticky bit
find /srv /home -xdev -type d -perm -0002 ! -perm -1000 2>/dev/null

-xdev penting: tanpa itu find akan menyeberang ke /proc dan mount lain, dan hasilnya penuh pesan error yang menenggelamkan temuan asli.

🔹 Langkah 8: baca jejak

Lapis terakhir menjawab pertanyaan yang paling sering ditanyakan atasan: siapa yang sebenarnya masuk.

last -n 10
lastlog | awk '$2!="**Never logged in**"'
journalctl _COMM=sudo --since "7 days ago" | tail -20

# ringkas percobaan login SSH yang gagal
grep -c 'Failed password' /var/log/auth.log 2>/dev/null

🧪 Uji cepat: journalctl _COMM=sudo hanya menampilkan eksekusi lewat sudo. Aktivitas yang dilakukan setelah user memperoleh shell root tidak lagi tercatat atas namanya — inilah alasan sudo lebih baik daripada su.

🔹 Langkah 9: perbaiki, lalu audit ulang

Perbaikan dilakukan berurutan dari risiko tertinggi, dan setiap langkah diikuti audit ulang.

# 1. tutup akun warisan: kunci password TIDAK cukup
usermod --expiredate 1 teknisi
rm -f /home/teknisi/.ssh/authorized_keys

# 2. hapus UID 0 kedua dan UID kembar
userdel -r tukang
userdel -r kembar

# 3. cabut kewenangan lewat group
gpasswd -d siswa3 sudo

# 4. rapikan file
rm -f /usr/local/bin/id-baru
chmod 1777 /srv/publik
chown -R root:root /srv/arsip-nilai
chmod 750 /srv/arsip-nilai

# 5. buktikan hasilnya
getent passwd | sort > /root/audit/passwd.after
getent group  | sort > /root/audit/group.after
diff /root/audit/passwd.before /root/audit/passwd.after
visudo -c

⚠️ Hati-hati: userdel -r menghapus direktori home. Untuk akun yang datanya masih diperlukan, arsipkan dulu dengan tar, baru hapus. Jangan pernah menjalankan userdel -r pada akun yang masih punya proses berjalan — lihat bagian troubleshooting.

🔹 Lembar temuan audit

Isi tabel ini sebelum dan sesudah perbaikan. Inilah bentuk laporan audit yang bisa dibaca orang non-teknis.

Temuan	Bukti	Tindakan
UID 0 kedua (tukang)	awk '$3==0'	userdel -r
UID kembar (siswa1/kembar)	uniq -d	userdel -r kembar
Akun L tapi punya kunci SSH	passwd -S, find -name authorized_keys	usermod --expiredate 1 + hapus kunci
Anggota group sudo tanpa tugas	getent group sudo	gpasswd -d
File yatim UID 4242	find -nouser	chown -R root:root
SUID di /usr/local/bin	find -perm -4000	hapus file
Folder 0777 tanpa sticky	find -perm -0002	chmod 1777

🏭 Dipakai di dunia kerja

• Sekolah dan lab TKJ: server ujian sering diwarisi antar guru. Audit serah terima mencegah akun lama dipakai mengubah nilai, dan membuat log bisa menunjuk satu nama.
• Kantor dan penyedia jasa IT: saat teknisi kontrak keluar, passwd -l sering dianggap cukup. Audit kunci SSH dan group adalah pembeda antara offboarding yang benar dan pintu belakang.
• Rumah sakit dan klinik: akses rekam medis harus bisa dipertanggungjawabkan per orang. UID kembar atau akun bersama membuat audit internal tidak bisa dijadikan bukti.
• ISP dan RT-RW Net: tim NOC sering berbagi satu akun admin agar cepat. Ketika konfigurasi pelanggan berubah, tidak ada yang bisa ditunjuk dan seluruh tim jadi tersangka.
• Industri dan manufaktur: akun vendor untuk mesin produksi biasanya bersifat sementara. Tanpa audit berkala, akun itu bertahan bertahun-tahun setelah kontrak selesai.
• Cloud dan VPS: audit akses adalah langkah pertama setelah insiden, karena snapshot bisa dipulihkan tapi bukti siapa masuk bisa hilang.

✅ Verifikasi

Jalankan ulang seluruh perintah audit. Semua baris harus berubah dari "ditemukan" menjadi "kosong".

Pemeriksaan	Sebelum	Sesudah
awk '$3==0' /etc/passwd	root, tukang	root saja
passwd -S teknisi	L	L + tanggal expire 1970
find /home -name authorized_keys	1 file	kosong
getent group sudo	siswa3 ada	siswa3 hilang
find / -xdev -nouser	/srv/arsip-nilai	kosong
find / -xdev -perm -4000	termasuk id-baru	hanya file bawaan
visudo -c	parsed OK	parsed OK

Perintah bukti akhir, jalankan berurutan:

sudo -l -U siswa3
sudo passwd -S teknisi
chage -l teknisi
ss -tnp | grep ':22'

sudo -l -U siswa3 harus menjawab bahwa user itu tidak boleh menjalankan apa pun. chage -l harus menunjukkan baris Account expires berisi tanggal lampau.

⚠️ Kesalahan umum & troubleshooting

🔹 Uji A: UID kembar membuat log berbohong

Buat dua nama dengan UID sama, lalu jalankan proses sebagai salah satunya.

useradd -m -o -u 1001 -s /bin/bash kembar
su - kembar -c 'sleep 300 &'
ps -o user,uid,cmd -C sleep

Kolom user menampilkan nama yang lebih dulu ada di /etc/passwd, padahal proses dijalankan oleh akun lain. Inilah kerusakan yang dicari audit: bukan aksesnya, tapi kesaksiannya.

🔹 Uji B: akun terkunci yang masih bisa masuk

passwd -l teknisi
passwd -S teknisi          # L
ls -l /home/teknisi/.ssh/authorized_keys

Status L hanya berarti password tidak bisa dipakai. Kunci SSH tetap bekerja, dan sshd akan mencatat Accepted publickey. Perbaikannya:

usermod --expiredate 1 teknisi
chage -l teknisi

🔹 Uji C: bedakan expire akun dan expire password

chage -E 0 siswa2      # akun langsung tidak bisa dipakai
chage -l siswa2
chage -E -1 siswa2     # batalkan
passwd -e siswa2       # ini hanya memaksa ganti password

chage -E menutup akun di lapisan PAM, jadi berlaku untuk semua cara login. passwd -e hanya membuat password kedaluwarsa dan user diminta menggantinya — akun tetap bisa dipakai.

🔹 Uji D: root tanpa jejak di sudoers

Tambahkan user ke group docker (kalau Docker terpasang di lab), lalu bandingkan dua pemeriksaan.

usermod -aG docker siswa1
sudo -l -U siswa1        # tampak tidak punya apa-apa
id siswa1

sudo -l bersih, tapi keanggotaan group memberi jalan setara root. Audit yang berhenti di sudoers akan melaporkan "aman" pada server yang tidak aman.

🔹 Uji E: NOPASSWD pada perintah yang bisa kabur

visudo -f /etc/sudoers.d/20-lab-audit
# isi: siswa1 ALL=(root) NOPASSWD: /usr/bin/find

Lalu dari akun siswa1:

sudo find /etc -maxdepth 0 -exec /bin/bash -p \;
id

Hasilnya shell root tanpa password. Aturan yang terlihat sempit bisa sama luasnya dengan ALL, tergantung program yang diizinkan. Ini alasan audit harus membaca nama program, bukan hanya jumlah baris.

🔹 Uji F: UID dipakai ulang mewarisi file lama

userdel karyawanlama          # sengaja tanpa -r
find /home -xdev -nouser -print
useradd -m -u 4242 karyawanbaru
ls -ln /srv/arsip-nilai

File lama sekarang milik karyawanbaru, karena kepemilikan tersimpan sebagai angka. Inilah cara paling halus kebocoran data antar karyawan: bukan hacking, hanya nomor yang dipakai ulang.

🔹 Uji G: SUID yang tidak pernah dipasang admin

install -m 4755 /usr/bin/id /usr/local/bin/id-baru
find / -xdev -perm -4000 -type f 2>/dev/null | sort
/usr/local/bin/id-baru

Perintah id biasa melaporkan UID pemanggil. Salinan SUID melaporkan euid=0. Simpan daftar SUID bawaan sistem sebagai pembanding, lalu periksa selisihnya setiap bulan.

🔹 Uji H: folder terbuka tanpa sticky bit

chmod 0777 /srv/publik
su - siswa2 -c 'touch /srv/publik/milik-siswa2'
su - siswa1 -c 'rm -f /srv/publik/milik-siswa2 && echo terhapus'

Dengan 1777, penghapusan itu ditolak. Dengan 0777, siapa pun bisa menghapus pekerjaan orang lain — masalah yang sama yang membuat /tmp wajib memakai sticky bit.

🔹 Uji I: password sudo masih tersimpan

sudo -v          # masukkan password sekali
sudo -l          # tidak diminta password lagi
sudo -k
sudo -l          # diminta password lagi

Bawaannya sudo menyimpan kredensial 15 menit per terminal. Di komputer lab bersama, ini berarti orang berikutnya bisa memakai sesi sudo yang masih hidup. Selalu akhiri dengan sudo -k.

Tabel pesan yang sering muncul saat audit:

Pesan	Arti	Tindakan
sudo: a password is required	dipanggil dengan -n tanpa cache	masukkan password atau pakai root
sudo: no tty present	dijalankan dari cron atau skrip	pakai -n dan atur aturan sempit
only root can use -U	sudo -l -U bukan dari root	jalankan sebagai root
userdel: user is currently used by process	masih ada proses berjalan	pkill -u, lalu ulangi
usermod: user is currently logged in	sesi login masih aktif	keluarkan sesi dulu
passwd: Authentication token manipulation error	/etc/shadow terkunci atau read-only	cek mount dan proses lain
visudo: syntax error	salah ketik di sudoers	perbaiki, jangan simpan
find: '/proc/...': Permission denied	menelusuri pseudo-filesystem	tambahkan -xdev dan 2>/dev/null
last: /var/log/wtmp: No such file	wtmp belum terbentuk	normal di container minimal

🔐 Catatan keamanan & etika

• Audit dulu, perbaiki kemudian. Kalau kamu menghapus lebih dulu, kamu kehilangan bukti dan tidak bisa membuktikan bahwa masalahnya pernah ada.
• Siapkan sesi root kedua. Sebelum mengubah sudoers atau PAM, buka satu terminal lain yang sudah login sebagai root. Kalau aturan baru salah, kamu masih punya jalan masuk.
• Jangan pernah mencetak isi /etc/shadow ke chat, tiket, atau grup. Hash password bisa dipecahkan di komputer lain tanpa meninggalkan jejak di server.
• Hasil audit berisi data pribadi. Nama user, jam login, dan alamat IP adalah data orang. Bagikan hanya ke pihak yang berwenang, dan sensor saat dipakai sebagai bahan ajar.
• Jangan menjalankan passwd -l sebagai "penutupan akun". Itu memberi rasa aman palsu. Pakai usermod --expiredate 1 plus pencabutan kunci.
• Etika lab bersama: mengaudit kewenangan orang lain di server sekolah hanya boleh dengan izin guru. sudo -l -U pada akun teman tanpa izin adalah mengintip, bukan belajar.
• Uji rusak hanya di VM. Membuat UID 0 kedua atau file SUID di server produksi adalah tindakan yang bisa berujung sanksi, meskipun niatnya latihan.

📌 Kesimpulan

Audit akses adalah pekerjaan mengubah kecurigaan menjadi daftar. Lima lapisnya sederhana: siapa bisa masuk, siapa bisa jadi root, apa yang boleh dilakukan, file mana yang terbuka, dan siapa meninggalkan jejak.

Yang paling sering luput bukan perintahnya, tapi kesimpulannya: akun terkunci belum tentu tertutup, sudo -l yang bersih belum tentu aman, dan file yatim bisa menjadi milik orang baru hanya karena nomor UID dipakai ulang.

Langkah berikutnya: simpan seluruh perintah audit tadi sebagai skrip /usr/local/sbin/audit-akses.sh, jalankan tiap awal bulan, dan simpan hasilnya dengan tanggal. Perubahan kecil antar bulan adalah tanda paling awal bahwa ada yang berubah tanpa kamu ketahui.

🔗 Materi terkait

• Linux : Manajemen User, Group, dan sudo — konsep tiga lapis identitas, keanggotaan, dan kewenangan.
• Linux : Manajemen User Dasar — perintah dasar membuat dan menghapus akun.
• Menambahkan User Baru di Debian — langkah pertama useradd dan adduser.
• Linux : Permission File dan Folder — membaca mode izin, SUID, dan sticky bit.
• Linux : Mengamankan SSH Server dengan Port Custom — memperkecil permukaan serangan di pintu masuk.
• Linux : Membatasi Percobaan Login SSH dengan Fail2ban — menangani brute force setelah audit menemukan pintunya.
• SSH:Private Key dan Public Key — memahami kunci yang membuat akun terkunci tetap bisa dipakai.
• Linux : Praktikum Membuat Service systemd dan Diagnosa Kegagalan Start — pola lab bukti berlapis dengan uji rusak terkendali.

📚 Referensi

• passwd(1) — Debian bookworm: arti -l, -u, -S, dan peringatan bahwa akun terkunci masih bisa login lewat token lain seperti kunci SSH.
• useradd(8) — Debian bookworm: opsi -o untuk UID tidak unik, -u, -G, dan rekomendasi adduser di Debian.
• usermod(8) — Debian bookworm: --expiredate, -L, -aG, dan peringatan mengganti daftar group tanpa -a.
• chage(1) — Debian bookworm: -E untuk tanggal kedaluwarsa akun, -l untuk membaca aging, -1 untuk membatalkan.
• sudo(8) — Debian bookworm: -l, -ll, -U, -k, dan cache kredensial 15 menit per terminal.
• sudoers(5) — Debian bookworm: urutan pembacaan, #includedir, aturan baris terakhir menang, dan timestamp_timeout.
• shadow(5) — Debian bookworm: struktur field password, arti !, dan perbedaan kedaluwarsa password dengan kedaluwarsa akun.
• sshd_config(5) — Debian bookworm: PubkeyAuthentication, PasswordAuthentication, PermitRootLogin.
• Debian Wiki — halaman sudo: alasan least privilege, akuntabilitas lewat log, dan verifikasi keanggotaan group sudo.