Panduan Lengkap Audit User di Server Linux: 5 Langkah 2026

Tolong ya, baca artikel ini dengan serius. Masalah yang mau aku bahas ini udah bikin aku jengkel dua kali dalam setahun terakhir, dan dua-duanya sebenarnya bisa dicegah dari awal. Kasusnya selalu sama: ada user di server yang seharusnya udah gak punya akses, tapi masih bisa login dan ganti-ganti sesuatu. Dan pas ketahuan, kita gak punya jejak sama sekali buat ngejelasin ke management. Ibarat rumah yang baru sadar kecurian tapi kamera CCTV-nya mati. Nah, jangan sampe kamu ngalamin itu.

Kali ini yang jadi bahan obrolan namanya Nguyen Hai Long. Dia kontraktor yang kontraknya udah selesai dua bulan lalu, tapi ternyata akunnya masih aktif di server production. Aku gak mau nyalahin dia sih, yang salah itu kita yang gak pernah punya proses offboarding yang bener. Dari situ aku belajar, dan sekarang artikel ini aku tulis biar kamu gak ngalamin kasus yang sama. Percaya deh, mending audit sekarang daripada nangis nanti. Ini bukan artikel teori, ini semua dari kejadian nyata yang mendarat di ticket aku.

Masalahnya bukan cuma soal satu user doang, lho. Ini soal pola. Kalau satu akun aja udah bisa kecolongan, coba bayangin kalau ada sepuluh mantan karyawan yang akunnya masih nangkring di server. Dampaknya ke production server itu jelas banget: risiko data breach, file yang diubah tanpa izin, dan yang paling bikin capek, kamu harus nebak-nebak siapa yang ngubah config di jam 3 pagi. Management gak akan seneng kalau jawabanmu cuma “aku gak tau siapa yang ubah ini, mas”. Dan percaya, di industri hosting, kasus kayak gini itu lebih sering kejadian dari yang orang mau akui. Banyak provider kecil yang gak sadar akun-akun lama masih punya akses penuh ke server client lain.

Dan yang lebih parah? Akun yang kelihatan “nggak penting” ini justru yang sering punya akses paling lebar. Ibarat pintu belakang rumah yang gak pernah kamu kunci, terus heran kok lemarinya kebongkar.

Sebelum kita mulai, penting buat kamu paham kenapa audit ini harus jadi kebiasaan, bukan cuma reaksi ketika ada masalah. Di environment production, setiap perubahan harus bisa dilacak balik ke siapa yang melakukannya. Ini bukan soal paranoid, ini soal akuntabilitas. Log Linux sebenarnya sudah nyimpen semua itu — login sukses, perintah sudo, sampai file yang diubah — tapi sayangnya banyak dari kita jarang mau buka log-nya. Nah, di artikel ini aku kasih 5 langkah yang bisa langsung kamu praktekin tanpa aplikasi tambahan. Cukup pakai perintah bawaan Linux. Lima langkah ini udah aku coba di server Ubuntu, Debian, dan CentOS, jadi kamu gak perlu khawatir beda distro bakal beda hasil.

Kenapa Audit Aktivitas User di Server Linux Itu Penting?

Oke, saiki kita bahas kenapa bagian ini sering banget dilewatin. Kebanyakan admin mikir, “ah, user-ku cuma dua, gak mungkin ada yang nakal.” Nah, itu persis pola pikir yang bikin masalah. Kasus Nguyen Hai Long tadi adalah contoh nyata: bukan karena dia jahat, tapi karena akun yang udah gak kepake itu tetap hidup, tetap bisa login, dan tetap bisa akses data sensitif. Satu kali login aja dari akun yang seharusnya mati itu udah cukup buat bikin config production berantakan.

Audit itu sebenernya sederhana: kamu mau tau siapa yang bisa masuk ke server kamu, siapa yang udah masuk, dan apa yang mereka lakuin. Tiga pertanyaan itu kalau dijawab pakai data log, kamu udah jadi admin yang jauh lebih tenang. Ibarat jaga rumah, kamu harus tau siapa yang pegang kunci, kapan mereka masuk, dan bawa apa pas keluar. Dan bonusnya, kalau ada audit trail yang rapi, kamu bisa tunjukin ke client atau management bahwa semuanya terkontrol.

Terus, audit juga bikin hidup kamu lebih gampang pas ada insiden. Waktu server tiba-tiba error dan kamu perlu tau siapa yang ubah config terakhir, kamu gak perlu tanya-tanya ke semua orang. Kamu tinggal buka log, dan jawabannya ada di situ. Gitu doang sih, tapi ini yang sering dilupain. Kalau kamu sering ngurusin server client, punya kebiasaan audit ini bakal ngebantu banget waktu ada komplain “serverku kok tiba-tiba melambat” atau “kok ada file aneh di folder web”.

5 Langkah Audit Aktivitas User di Server Linux

Langsung aja ke intinya. Lima langkah di bawah ini urut dari yang paling simpel ke yang paling dalam. Kamu gak perlu install apa-apa, semua pakai tools bawaan. Dan inget, tulis hasilnya atau simpen output-nya ke file, karena kamu bakal butuh itu buat laporan. Mulai dari yang paling jarang berubah: daftar user. Setelah itu baru kita masuk ke log-log yang lebih hidup.

Langkah 1: Buat Daftar Semua User yang Ada di Server

Pertama, kita lihat dulu siapa aja yang punya akun. File /etc/passwd nyimpen daftar user, tapi gak semua entry di situ adalah user “beneran” — banyak yang system user. Yang perlu kamu perhatiin itu user dengan UID 1000 ke atas.

cat /etc/passwd

awk -F: '$3 >= 1000 {print $1, $6}' /etc/passwd

Output yang diharapkan kira-kira kayak gini (identitas udah disensor):

root /root
nguyenhalong /home/nguyenhalong
dewirahayu /home/dewirahayu
admin-backup /home/admin-backup
www-data /var/www
sshd /run/sshd

Nah, dari sini kamu bisa langsung liat anomali. Contoh: ada user admin-backup yang mungkin udah gak dipake tapi masih ada. Kalau kamu nemu user yang gak kamu kenal atau udah gak relevan, catat dulu. Jangan langsung hapus — nanti di langkah terakhir kita bahas. Perhatiin juga home directory-nya, karena itu nunjukin kapan-kapan kita bisa cek file aktivitasnya. Di server hosting, biasanya user dengan UID 1000 ke atas itu akun yang dibikin manual, sementara akun cPanel punya pola sendiri.

Perintah kedua pakai awk untuk nge-filter user dengan UID 1000 ke atas. Ini cara cepat buat pisahin user manusia dari user sistem. Nggih, gak semua UID 1000+ itu manusia, tapi 99% kasus di VPS/hosting itu user cPanel atau user yang dibuat admin. Kalau output-nya panjang, jangan ragu buat simpen ke file dulu: awk -F: ‘$3 >= 1000 {print $1, $6}’ /etc/passwd > /tmp/daftar-user.txt. Itu bakal jadi baseline audit kamu.

Langkah 2: Cek Siapa yang Pernah Login dan Kapan

Sekarang kita masuk ke bagian yang paling penting: riwayat login. File /var/log/wtmp dan /var/log/btmp nyimpen data login, dan kamu bisa baca pakai perintah last.

last -a

Output-nya bakal nunjukin daftar login sukses, lengkap dengan IP asal dan tanggalnya. Contoh:

nguyenhalong pts/1 203.0.113.10 Sat Jul 18 22:14 still logged in
dewirahayu pts/0 198.51.100.5 Sat Jul 18 20:02 - 22:10 (02:08)
root pts/0 192.0.2.50 Sat Jul 18 09:31 - 10:45 (01:14)

Kalau kamu mau cek login yang gagal, pakai lastb. Perhatiin — lastb butuh akses root karena baca /var/log/btmp:

lastb | head -30

Nah, ini yang bikin aku dulu kaget. Waktu aku cek last untuk kasus Nguyen Hai Long, ternyata akunnya masih login aktif seminggu terakhir, padahal kontraknya udah selesai. Gila, kan? Dari situ aku langsung tau kalau offboarding kita emang bocor. Kamu juga harus perhatiin kolom IP-nya. Kalau ada login dari IP yang gak lazim, atau dari negara yang gak masuk akal buat tim kamu, itu tanda buat dilacak lebih lanjut.

Buat cek user yang lagi online sekarang, pakai perintah who atau w:

who
w

Perintah w itu lebih lengkap, dia nunjukin juga apa yang lagi dikerjain user (command yang jalan). Berguna banget pas lagi curiga ada yang lagi ngapa-ngapain di server. Kalau kamu nemu session yang kelewat lama gak kepake, itu juga bahan buat diperhatiin — bisa jadi session yang di-keep open tanpa sengaja.

Langkah 3: Telusuri Aktivitas Sudo dan Privilege

Login aja gak cukup buat dapet gambaran utuh. Banyak kerusakan di server itu lewat perintah sudo, dan untungnya semua itu tercatat di log autentikasi. Di Ubuntu/Debian log-nya ada di /var/log/auth.log, di CentOS/RHEL ada di /var/log/secure.

grep sudo /var/log/auth.log | tail -30

journalctl -u sudo --since "2026-07-01"

Output contoh yang bakal kamu liat:

Jul 18 22:20:01 web-prod-1 sudo: nguyenhalong : TTY=pts/1 ; PWD=/home/nguyenhalong ; USER=root ; COMMAND=/bin/chown -R www-data:www-data /var/www/html

Liat baris itu? Itu artinya user nguyenhalong jalanin perintah chown dengan privilege root. Kalau user-nya udah gak seharusnya pegang akses, ini red flag. Simpen semua baris yang mencurigakan ke file buat dokumentasi:

journalctl -u sudo --since "2026-01-01" > /tmp/audit-sudo.log

Tapi inget ya, ini buat dokumentasi, bukan buat hal aneh-aneh. Output log ini berisi informasi sensitif, jadi jangan di-share ke tempat publik. Kalau mau nunjukin ke client, sensor dulu IP dan username-nya. Banyak admin yang lupa hal sepele ini, terus kaget pas datanya ketahuan nyebar.

Langkah 4: Periksa SSH Key dan Akses yang Masih Terbuka

Ini langkah yang paling sering kelewat dan justru paling bahaya. Satu SSH key yang masih nyangkut di authorized_keys bisa jadi jalan masuk permanen ke server kamu, bahkan kalau password udah diganti. Cek isi folder .ssh tiap user:

ls -la /home/*/.ssh/
cat /home/*/.ssh/authorized_keys

Perhatiin output-nya. Kalau ada key yang kamu gak kenal atau key milik mantan karyawan, itu warning. Contoh key yang harus kamu curigain kalau gak tau pemiliknya:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDBq...D/8zcVc2pZ7 user@laptop-lama

Buat bandingin, kamu bisa lihat key public apa aja yang terdaftar di known_hosts server atau di GitHub user yang bersangkutan. Kalau ragu, key itu harus dicabut. Tapi jangan hapus dulu — copy dulu isinya ke file, karena kamu mungkin butuh buat investigasi siapa yang nambahin key itu. Dan jangan lupa cek juga file authorized_keys di root, karena banyak admin yang kena gara-gara root punya key yang gak jelas asal-usulnya.

Mau tau cara baca format key SSH? Baca juga artikel kami soal cara membaca dan mengelola SSH key biar gak salah langkah.

Langkah 5: Lacak Perubahan File dan Config

Langkah terakhir ini buat jawab pertanyaan “siapa yang ubah apa, kapan?”. Ada beberapa cara. Yang paling gampang buat mulai: cari file yang baru diubah dalam periode tertentu.

find /etc -type f -newermt "2026-07-01" -not -path "*/cache/*" 2>/dev/null | head -30

Output-nya daftar file config yang berubah sejak 1 Juli. Kalau ada file yang kamu gak inget ngeditnya, itu bahan investigasi. Untuk cek detail file tertentu, pakai stat:

stat /etc/ssh/sshd_config

Buat pengawasan yang lebih ketat dan berkelanjutan, kamu bisa aktifkan auditd. Tapi itu butuh setup lebih lanjut, dan bahasannya bisa panjang. Kalau kamu mau lebih serius soal keamanan server, cek dulu artikel cara mengamankan SSH server dari brute force sebagai langkah pertama.

Tabel Ringkasan: Log yang Perlu Kamu Tahu

Setelah Ketemu Anomali: Lakukan Ini

Nah, ini bagian yang sering bikin orang grusa-grusu. Ketemu akun mencurigakan, langsung pengen hapus. Stop. Jangan. Langkah-langkah di bawah ini wajib kamu ikutin berurutan biar gak bikin masalah baru. Ingat, tujuannya bukan cuma nutup akses, tapi juga ngejaga bukti dan ngejamin kamu gak salah target.

Pertama, dokumentasikan semuanya. Simpen output dari lima langkah di atas, lengkap dengan tanggal dan jam kamu ambil data-nya. Ini penting buat laporan ke client atau management, dan bisa jadi bukti kalau sewaktu-waktu ada yang nanya. Kedua, verifikasi dulu bahwa user yang kamu curigain itu memang user yang bener. Jangan sampe salah tangkap — pernah ada kasus di lapangan, admin nge-hapus akun yang ternyata dipake tim lain buat backup. Rame deh.

Setelah semua terverifikasi, baru kamu bisa nonaktifkan akun dengan cara yang reversible dulu. Contoh: kunci password user, bukan langsung hapus akunnya. Kalau ternyata salah, masih gampang balikin.

passwd -l nguyenhalong

Atau kalau mau cabut akses SSH tanpa ngubah password:

mv /home/nguyenhalong/.ssh/authorized_keys /home/nguyenhalong/.ssh/authorized_keys.bak-20260718

Dua perintah di atas itu gak ngehapus data, cuma ngunci akses. Jadi masih aman buat dibalikin. Penghapusan akun total (userdel) itu baru langkah terakhir, dan itu butuh keputusan yang lebih matang plus backup penuh. Jangan pernah userdel langsung tanpa proses di atas.

Pro Tips dan Warning dari Pengalaman

Setelah lakuin ini berkali-kali, ada beberapa hal yang selalu aku ulang-ulang ke tim dan mungkin bermanfaat buat kamu:

• Jadwalkan audit minimal sebulan sekali. Jangan nunggu ada insiden baru audit. Kalau audit cuma dilakukan pas lagi ada masalah, kamu bakal sering telat. Cukup 15 menit, dan kamu bisa pake checklist yang sama.
• Bikin proses offboarding yang jelas. Begitu karyawan atau kontraktor keluar, langsung matikan akunnya. Jangan tunggu minggu depan. Satu minggu itu sudah lama banget buat yang berniat jahat.
• Jangan pernah share log mentah ke publik. Log itu berisi IP, username, dan pola akses internal. Kalau mau share buat belajar, sensor dulu. Ini aturan yang sering dilanggar dan bisa berujung masalah serius.
• Simpen baseline. Simpen output audit pertama kamu sebagai pembanding. Perbedaan dari baseline itu lebih penting daripada daftar mentahnya.
• Kalau kamu pake cPanel atau panel lain, jangan lupa audit di level panel juga. Artikel cara cek user aktif di cPanel/WHM bisa bantu.
• Dan terakhir, kalau tim kamu gede, bikin dokumentasi prosedurnya. Karena audit yang cuma nangkring di kepala satu orang itu rapuh — begitu orangnya cuti atau resign, prosedurnya ikut hilang.

Soal backup juga jangan dilupain ya. Ini bukan langkah audit langsung, tapi kalau kamu nemu anomali dan mau bertindak (misalnya mau matikan akun atau cabut key), pastiin dulu data penting udah dibackup. Perintah yang sifatnya merubah atau menghapus akses gak boleh dijalanin tanpa backup dan verifikasi, karena bisa bikin data loss permanen. Kalau butuh referensi soal resource server, cek juga artikel troubleshoot high load di server cPanel yang di dalamnya ada tips jaga performa production.

FAQ Audit Aktivitas User di Server Linux

Artikel Terkait

• Cara Mengamankan SSH Server dari Brute Force
• Cara Membaca dan Mengelola SSH Key
• Monitoring Log Server dengan Journald
• Cara Cek User Aktif di cPanel/WHM
• Troubleshoot High Load di Server cPanel

Tolong ya, jangan ngulang kesalahan yang sama. Audit itu cuma butuh 15 menit sebulan, tapi efeknya ke keamanan server kamu itu besar banget. Kasus kayak Nguyen Hai Long ini gak harus kejadian terus-terusan. Pelajarin langkah-langkah di atas, bikin proses offboarding, dan take it seriously. Karena begitu kamu abai, yang susah itu bukan cek log-nya, tapi jelasin ke client kenapa data mereka bocor. Kalau kamu nemu kasus aneh lain, drop di komentar ya — siapa tau bisa bantu tim lain yang lagi ngalamin hal sama.