Audit Perintah Pengguna di Server dengan Auditd

Apa yang sebenarnya mencatat perintah yang dijalankan pengguna di server Anda

Untuk mengaudit perintah yang dijalankan pengguna di server, Anda memerlukan catatan yang tidak dapat diedit oleh pengguna tersebut. Riwayat shell bukan catatan itu. Riwayat shell adalah file praktis yang dimiliki oleh akun yang menulisnya. Siapa pun yang dapat mengetik pada shell tersebut dapat menonaktifkan atau menghapusnya.

Empat lapisan dapat menyimpan catatan yang sebenarnya, dan masing-masing memiliki konsekuensi. sudo menulis satu baris per perintah ke syslog. Pencatatan I/O sudo merekam seluruh sesi untuk satu akun. Hook shell seperti PROMPT_COMMAND mencatat apa yang diketik pengguna bash interaktif. Subsistem audit kernel mencatat syscall execve itu sendiri. Karena itu, hanya lapisan ini yang dapat melihat setiap proses. Panduan ini membahas setiap lapisan secara bertahap, menjelaskan batasannya, lalu membahas hal yang menentukan apakah semua ini benar-benar berguna: mengirim catatan keluar dari mesin sebelum orang yang sedang Anda audit dapat mengaksesnya.

Perhatikan satu hal sebelum memulai. Subsistem audit berjalan di kernel. Karena itu, semua ini tidak dapat diuji di dalam container yang menggunakan kernel host bersama. Jalankan perintah ini pada VPS KVM dengan kernel yang Anda kendalikan.

Mengapa riwayat shell bukan jejak audit

~/.bash_history gagal digunakan sebagai bukti karena empat alasan umum, dan tidak satu pun memerlukan penyerang yang canggih.

File tersebut milik pengguna. File itu memiliki mode 600 dan dimiliki oleh akun tersebut, sehingga rm ~/.bash_history tidak memerlukan hak istimewa sama sekali. Membukanya di editor lalu menghapus dua puluh baris yang penting juga tidak memerlukan hak istimewa.

File tersebut ditulis saat shell keluar. Sesi yang berakhir dengan kill -9 $$, atau dengan koneksi yang terputus, tidak menulis apa pun. history -c sebelum exit memiliki efek yang sama dan tampak seolah-olah tidak terjadi apa-apa.

Fitur ini dapat dinonaktifkan dengan satu kata. unset HISTFILE menghentikan penulisan file untuk sesi tersebut. set +o history segera menghentikan perekaman. HISTCONTROL=ignorespace menyembunyikan setiap perintah yang diketik dengan spasi di awal. Semua ini diatur dalam man bash karena memang dimaksudkan untuk dikendalikan oleh pengguna.

Yang direkam adalah teks yang diketik, bukan yang dijalankan. Alias atau fungsi shell berarti teks dalam file bukanlah program yang dijalankan oleh kernel.

Riwayat tersebut juga tidak memiliki timestamp, kecuali HISTTIMEFORMAT telah ditetapkan saat entri ditulis, karena bash hanya menulis baris penanda #1755043200 jika variabel tersebut ditetapkan.

Pada login bersama, riwayat tersebut juga tidak dapat memberi tahu siapa yang menjalankan perintah. Tiga orang yang menggunakan satu akun deploy menghasilkan satu file yang saling tercampur di bawah satu uid. Tidak ada lapisan logging yang dapat mengaitkan suatu tindakan dengan manusia tertentu jika dua manusia berbagi satu uid. Inilah alasan praktis untuk menggunakan satu akun tanpa hak istimewa untuk setiap orang, bukan login bersama.

Riwayat shell berguna untuk tujuan sebenarnya, yaitu membantu Anda mengetik ulang perintah kemarin. Gunakan riwayat tersebut sebagai petunjuk. Jangan pernah menyajikannya sebagai bukti.

Yang dicatat sudo dan batas pencatatannya

sudo mengirimkan satu baris untuk setiap perintah yang dijalankannya ke fasilitas syslog authpriv.

sudo grep 'sudo:' /var/log/auth.log | tail -5
journalctl -t sudo -n 5

Setiap baris mencantumkan pengguna, terminal, direktori kerja, pengguna target, dan perintah:

sudo:    alice : TTY=pts/0 ; PWD=/home/alice ; USER=root ; COMMAND=/usr/bin/apt update

Jika /var/log/auth.log tidak ada, rsyslog tidak terpasang pada image tersebut dan catatan yang sama hanya tersedia di journal. Pastikan journal tidak bersifat volatil sebelum Anda mengandalkannya:

journalctl --list-boots

Jika hanya boot saat ini yang tercantum, berarti /var/log/journal tidak ada. Journal tersimpan di /run dan setiap baris akan hilang saat reboot berikutnya. Jadikan journal persisten:

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald

Sekarang batasnya. sudo mencatat perintah yang diminta untuk dijalankan. sudo tidak mencatat tindakan yang kemudian dilakukan oleh perintah tersebut. Karena itu, satu baris dapat mengakhiri jejak pencatatan:

sudo -i

Log hanya memiliki satu catatan untuk shell tersebut. Setiap perintah yang diketik di dalam root shell itu tidak terlihat oleh sudo karena sudo tidak lagi berada dalam jalur eksekusi. sudo su -, sudo bash, dan sudo vim /etc/shadow yang diikuti oleh :!bash memiliki bentuk yang sama. Aturan sudoers yang mengizinkan program apa pun dengan shell escape, seperti vim atau find, merupakan aturan yang memberikan akses root tanpa pencatatan. Periksa apa saja yang benar-benar dapat dijangkau oleh suatu akun sebelum mempercayai baris lognya:

sudo -l -U alice

Merekam sesi lengkap untuk satu akun

Pertama, cari tahu sudo yang Anda gunakan, karena fitur ini tidak tersedia dalam penulisan ulang Rust:

sudo --version | head -1

Jika output menampilkan sudo-rs, lewati bagian ini dan gunakan subsistem audit. Dokumentasi resmi Ubuntu untuk rilis 25.10 dan 26.04 mencantumkan pencatatan I/O dan sudoreplay sebagai fitur yang tidak didukung, dan kondisi tersebut masih berlaku pada Agustus 2026. Hal ini penting karena sudo-rs adalah sudo default pada rilis tersebut. Dengan demikian, upgrade dapat menghapus kontrol yang Anda kira masih tersedia. Daftar lengkap perubahan perilaku sudo-rs sebaiknya dibaca sebelum Anda merencanakan pencatatan berbasis sudo.

Dengan sudo asli, yang masih disertakan Ubuntu 24.04 LTS, aktifkan pencatatan I/O untuk satu akun:

sudo visudo -f /etc/sudoers.d/iolog

Defaults:deploy log_output
Defaults!/usr/bin/sudoreplay !log_output

Gunakan visudo, bukan editor, karena perintah tersebut menolak menyimpan file yang tidak dapat diuraikan. File sudoers yang rusak dapat mengunci semua pengguna dari sudo. Kemudian, putar ulang sesi:

sudo sudoreplay -l user=deploy
sudo sudoreplay 000001

sudoreplay -l mencantumkan sesi beserta ID-nya dan tidak mencetak apa pun jika log_output tidak pernah diterapkan kepada pengguna tersebut. Biayanya adalah setiap byte yang melewati terminal disimpan di bawah /var/log/sudo-io, sehingga sesi yang banyak menghasilkan output dapat berukuran besar. Baris sudoers kedua mencegah proses pemutaran ulang ikut direkam. Biaya sebenarnya berkaitan dengan rahasia, karena log I/O menyimpan apa pun yang diketik dan dicetak, termasuk kata sandi yang diketik pada prompt di dalam sesi. Karena itu, log tersebut memerlukan perlindungan yang sama seperti penyimpanan kata sandi. Cakupannya juga terbatas. Sistem hanya merekam perintah yang dijalankan melalui sudo. Pengguna yang login dan bekerja sepenuhnya sebagai dirinya sendiri tidak direkam sama sekali.

Shell hook dan cara melewatinya secara tepat

Resep yang beredar untuk "mencatat setiap perintah" adalah hook PROMPT_COMMAND yang ditempatkan di /etc/profile.d/:

# /etc/profile.d/00-cmdlog.sh
PROMPT_COMMAND='logger -p local6.info -t cmdlog "$(whoami) $$ $(history 1 | sed "s/^ *[0-9]* *//")"'

bash menjalankan PROMPT_COMMAND sebelum menampilkan setiap prompt. Karena itu, satu baris dikirim ke syslog saat diketik, bukan saat shell keluar. logger menulis melalui daemon log sistem, sehingga izin file milik pengguna tidak berpengaruh. Buka login shell baru, lalu periksa dengan sudo tail -f /var/log/syslog, atau gunakan journalctl -t cmdlog -f pada image tanpa rsyslog.

Kemudian mekanisme ini berhenti bekerja melalui lima cara berikut. Masing-masing dapat Anda reproduksi dalam satu menit.

• Shell non-interaktif tidak pernah menampilkan prompt. ssh you@server 'id' menjalankan perintah lalu selesai, dan tidak ada yang dicatat karena PROMPT_COMMAND tidak pernah dievaluasi.
• Mekanisme ini berupa variabel. unset PROMPT_COMMAND menonaktifkannya selama sisa sesi dan tidak memerlukan hak istimewa.
• File tersebut dibaca oleh login shell. bash --noprofile --norc sama sekali tidak mengambil sumber /etc/profile.d/.
• Mekanisme ini khusus untuk bash. zsh, sh, python3 -c 'import os; os.system("id")', dan :!id di dalam vim semuanya menjalankan program yang tidak akan pernah terlihat oleh hook prompt bash.
• Mekanisme ini mencatat baris sebagaimana diketik. Karena itu, alias atau fungsi tetap menyembunyikan perintah yang sebenarnya dijalankan.

Gunakan shell hook sebagai kemudahan. Mekanisme ini dapat menjawab pertanyaan "perintah apa yang saya jalankan Selasa lalu" untuk pengguna yang bekerja sama. Jangan biarkan checklist menganggapnya sebagai kontrol.

Subsistem audit kernel mencatat setiap execve

Subsistem audit Linux, yang dijalankan oleh daemon auditd, adalah satu-satunya lapisan di sini yang tidak dapat dilewati pengguna karena catatan dibuat di dalam kernel saat syscall dijalankan. Jika suatu proses mengeksekusi program, sebuah event akan tercatat. Shell, bahasa, dan ada atau tidaknya terminal tidak berpengaruh.

sudo apt update && sudo apt install -y auditd audispd-plugins
sudo systemctl enable --now auditd
sudo auditctl -s

auditctl -s menampilkan status daemon. enabled 1 dengan nilai pid yang bukan nol berarti daemon sedang berjalan, sedangkan lost 0 berarti belum ada catatan yang dibuang. Ingat counter lost tersebut. Counter itu akan muncul lagi nanti.

auid adalah field yang membuat audit sepadan dengan upaya yang diperlukan. PAM menetapkan login uid saat session dimulai, lalu kernel membawanya ke setiap child process setelah itu. Periksa nilai Anda:

cat /proc/self/loginuid

Session SSH interaktif menampilkan uid Anda karena /etc/pam.d/sshd menyertakan pam_loginuid.so. Nilai 4294967295 berarti loginuid belum pernah ditetapkan. Hal ini normal untuk proses yang dimulai oleh system daemon saat boot. Bagian pentingnya adalah sudo -i tidak mengubahnya: root shell yang dibuka oleh alice tetap membawa auid 1000, sehingga setiap command di dalamnya dapat dikaitkan dengan alice. Inilah celah yang dibiarkan oleh sudo. Mengubah loginuid yang sudah ditetapkan memerlukan CAP_AUDIT_CONTROL, yang tidak dimiliki pengguna biasa, dan sudo auditctl --loginuid-immutable juga menutup celah tersebut untuk root sampai reboot berikutnya.

Pastikan /etc/pam.d/sshd, /etc/pam.d/login, dan /etc/pam.d/cron masing-masing menyertakan pam_loginuid.so. Jika tidak, event akan tiba tanpa identitas yang terkait. Daftar file tersebut sama dengan yang Anda ubah saat memperkuat akses SSH pada VPS, jadi lakukan kedua pekerjaan tersebut secara bersamaan.

Aturan awal untuk auditd

Aturan disimpan di /etc/audit/rules.d/*.rules. augenrules menggabungkannya berdasarkan urutan nama file menjadi satu daftar. Urutan menentukan perilaku karena kernel berhenti pada aturan pertama yang cocok. Baca isi yang sudah ada sebelum menambahkan apa pun karena -D pada file berikutnya menghapus semua aturan yang telah dimuat sebelumnya.

ls /etc/audit/rules.d/
cat /etc/audit/rules.d/audit.rules

Kemudian tulis /etc/audit/rules.d/50-exec.rules:

## Suppressions first: the kernel takes the first matching rule.
-a never,exit -F arch=b64 -S execve -F exe=/usr/bin/dpkg
-a never,exit -F arch=b64 -S execve -F exe=/usr/bin/dpkg-deb
-a never,exit -F arch=b64 -S execve -F exe=/usr/bin/dpkg-query
-a never,exit -F arch=b64 -S execve -F exe=/usr/bin/dpkg-split
-a never,exit -F arch=b64 -S execve -F exe=/usr/bin/dpkg-trigger

## Every program started by a logged-in human.
-a always,exit -F arch=b64 -S execve,execveat -F auid>=1000 -F auid!=unset -k exec
-a always,exit -F arch=b32 -S execve,execveat -F auid>=1000 -F auid!=unset -k exec

## Changes to who may become root.
-w /etc/sudoers -p wa -k sudoers
-w /etc/sudoers.d/ -p wa -k sudoers
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/group -p wa -k identity

## Changes to the audit configuration itself.
-w /etc/audit/ -p wa -k auditconfig

Muat aturan tersebut dan lakukan konfirmasi:

sudo augenrules --load
sudo auditctl -l

auditctl -l yang mencetak ulang aturan berarti aturan tersebut aktif. No rules berarti pemuatan gagal, sedangkan journalctl -u auditd -n 20 menunjukkan nama file dan baris yang ditolak parser. Userspace audit versi lama tidak memahami kata kunci unset. Jika loader melaporkan masalah pada field tersebut, gunakan -F auid!=4294967295 sebagai gantinya. Nilainya sama, tetapi ditulis lengkap.

Sekarang baca kembali event:

sudo ausearch -k exec -ts recent -i | tail -40
sudo ausearch -ul 1000 -ts today -i
sudo aureport -k --summary -i

-i mengubah uid dan nomor syscall menjadi nama. Dalam praktiknya, opsi ini wajib digunakan. -ts recent mencakup sepuluh menit terakhir. Setiap eksekusi menghasilkan sekumpulan record: record SYSCALL yang memuat uid, auid, status exit, dan key; record EXECVE yang memuat daftar argumen lengkap; serta record CWD dan PATH untuk konteks.

Ada satu batasan penting yang sering menimbulkan kesalahpahaman. audit mencatat syscall, sedangkan shell builtin tidak menjalankan syscall atas namanya sendiri. cd /root tidak menjalankan program. echo evil >> /etc/passwd yang diketik pada prompt bash juga tidak menjalankan program karena echo dan redirect berlangsung di dalam proses shell yang sudah berjalan. Jadi, aturan execve melihat program, sedangkan aturan -w melihat operasi penulisannya. Tidak satu pun cukup jika digunakan sendiri.

Terakhir, kunci konfigurasi:

## /etc/audit/rules.d/99-finalize.rules
-e 2

-e 2 membuat kumpulan aturan tidak dapat diubah hingga reboot berikutnya. Setelah aturan dimuat, auditctl -s melaporkan enabled 2, dan setiap upaya untuk menambahkan atau menghapus aturan gagal dengan Operation not permitted, termasuk jika dilakukan oleh root. Tambahkan file ini terakhir dan perkirakan reboot setiap kali ingin mengubah aturan. Konsekuensinya memang demikian: kumpulan aturan yang dapat diam-diam dinonaktifkan oleh siapa pun bukanlah bukti.

Log audit yang tidak pernah dibaca siapa pun hanyalah artefak kepatuhan

Kegagalan auditd bukan karena auditd melewatkan kejadian. Masalahnya adalah auditd mencatat begitu banyak hal sehingga tidak ada yang membacanya, lalu log tersebut hanya ada untuk memenuhi daftar periksa, bukan untuk menjawab pertanyaan.

Lakukan perhitungan pada server Anda sendiri sebelum menyesuaikan konfigurasi apa pun:

sudo aureport -k --summary -i
sudo du -sh /var/log/audit

Satu sudo apt upgrade menjalankan ribuan proses berumur pendek, dan setiap proses membawa auid Anda. Karena itu, satu pembaruan paket dapat menghasilkan lebih banyak entri daripada aktivitas pengetikan manusia selama seminggu. Itulah alasan pengecualian di atas mencantumkan dpkg dan helper-nya. Terapkan pengecualian berdasarkan executable, bukan user: pengecualian untuk /usr/bin/dpkg adalah celah yang dapat Anda jelaskan dalam satu kalimat, sedangkan pengecualian untuk sebuah akun memiliki bentuk celah yang persis sama dengan hal yang ingin Anda deteksi.

Key -k pada setiap rule membuat log dapat dicari sebulan kemudian. ausearch -k sudoers adalah pertanyaan yang memiliki jawaban. ausearch tanpa filter hanyalah dinding teks yang melatih Anda untuk berhenti membaca. Jika collector Anda memerlukan JSON, bukan format native, laurel adalah plugin auditd yang menulis ulang setiap event sebagai satu objek JSON dengan argumen yang sudah didekode. Plugin ini didaftarkan di /etc/audit/plugins.d/ seperti plugin lainnya, dan auditd memuat perubahan plugin pada sudo pkill -HUP auditd.

Biaya auditd secara realistis

Setiap syscall yang cocok menjadi sebuah record yang diformat oleh kernel lalu diserahkan ke userspace. Biayanya muncul di dua tempat. Keduanya dapat diukur pada workload Anda sendiri, bukan ditebak dari angka yang dipublikasikan untuk workload orang lain.

• CPU dan latensi. Mesin yang sering melakukan fork, seperti host build atau runner CI, menghasilkan satu record untuk setiap exec. Saat backlog kernel penuh, --backlog_wait_time membuat kernel menangguhkan proses yang menghasilkan event hingga tersedia ruang. Akibatnya, audit terlihat sebagai build yang lebih lambat, bukan sebagai persentase penggunaan CPU. Pantau backlog dan lost dalam sudo auditctl -s saat beban nyata berlangsung. Nilai lost yang meningkat berarti ada record yang terhapus. Log dengan celah yang tidak terlihat lebih buruk daripada tidak memiliki log, karena Anda tetap akan mempercayainya.
• Disk. Baca /etc/audit/auditd.conf dan tentukan secara sengaja tindakan yang dilakukan saat disk penuh, karena nilai bawaan yang disertakan adalah pilihan desain. max_log_file, num_logs, dan max_log_file_action mengontrol rotasi. space_left_action, admin_space_left_action, dan disk_full_action mengontrol kondisi darurat. Beberapa tindakan yang tersedia, termasuk halt dan single, mematikan mesin daripada kehilangan sebuah record.

Baris -f dalam /etc/audit/rules.d/audit.rules adalah keputusan yang sama pada tingkat kernel: -f 1 melaporkan kegagalan audit ke syslog, sedangkan -f 2 membuat kernel panic. Pilih 2 hanya jika Anda benar-benar lebih memilih kehilangan server daripada kehilangan sebuah record. Pada VPS yang menjalankan layanan yang diandalkan orang lain, gunakan rotasi. Pindahkan masalah penyimpanan ke luar server tersebut.

Kirim log ke luar server, hampir secara real time

Bagian ini terus terbukti dalam laporan insiden. Log yang tetap berada di host yang telah dibobol dapat diedit oleh pihak yang membobolnya. root dapat menulis ulang /var/log/auth.log, menghapus /var/log/audit/audit.log, dan menghentikan daemon. -e 2 mencegah aturan dibongkar. Namun, fitur ini tidak melindungi rm. Setiap lapisan di atas hanya menghasilkan bukti jika salinannya terlebih dahulu keluar dari mesin.

Transport bawaan Audit adalah plugin audisp-remote dari audispd-plugins. Aktifkan plugin tersebut di /etc/audit/plugins.d/au-remote.conf:

active = yes
direction = out
path = /usr/sbin/audisp-remote
type = always
format = string

Periksa path terhadap command -v audisp-remote sebelum memuat ulang konfigurasi, karena path yang salah hanya menghasilkan satu baris di journal tanpa mengirimkan apa pun. Atur remote_server dan port di /etc/audit/audisp-remote.conf, lalu pada collector atur tcp_listen_port = 60 di auditd.conf miliknya. Muat ulang dengan sudo pkill -HUP auditd. Pada banyak image, systemctl restart auditd ditolak karena file unit menetapkan RefuseManualStop=yes. Karena itu, gunakan rute signal yang lebih andal.

Pilihan lain memasukkan Audit ke dalam aliran syslog yang sudah Anda teruskan. /etc/audit/plugins.d/syslog.conf disertakan dalam active = no. Atur nilainya menjadi yes, muat ulang, lalu event Audit akan bergabung dengan baris sudo dan semua log lainnya. Selanjutnya, teruskan seluruhnya dengan rsyslog melalui TLS (transport layer security), yang memerlukan package rsyslog-gnutls:

# /etc/rsyslog.d/60-forward.conf
*.* action(type="omfwd"
    target="logs.example.net" port="6514" protocol="tcp"
    StreamDriver="gtls" StreamDriverMode="1"
    StreamDriverAuthMode="x509/name"
    StreamDriverPermittedPeers="logs.example.net"
    action.resumeRetryCount="-1"
    queue.type="linkedList" queue.filename="fwd" queue.saveOnShutdown="on")

Bagian yang penting adalah pengaturan queue. action.resumeRetryCount="-1" mencoba ulang tanpa batas, sedangkan queue berbantuan disk dengan queue.saveOnShutdown="on" menyimpan record selama collector tidak dapat dijangkau, lalu mengirimkannya kembali setelah collector tersedia. Tanpa kedua pengaturan tersebut, reboot pada collector meninggalkan celah dalam bukti Anda tanpa memberi tahu bahwa celah itu ada. Terapkan dengan sudo systemctl restart rsyslog, lalu pastikan record benar-benar tiba di collector sebelum Anda mengandalkannya.

Masih ada satu loop yang harus ditutup: collector harus berupa mesin yang tidak dapat digunakan untuk login oleh orang yang diaudit. Jika grup admin yang sama memiliki akses root pada server log, Anda hanya menyalin file, bukan melindunginya. Gunakan kredensial terpisah, key terpisah, dan idealnya account provider terpisah. Alasan yang sama membuat cara terpusat untuk mengelola banyak server Linux layak dibangun sebelum diperlukan. Hal ini juga menentukan perbedaan antara satu jam pertama yang berguna dan yang sia-sia ketika Anda menangani VPS yang telah dibobol.

Pastikan pengguna biasa tidak dapat menulis ulang catatan

Uji klaim tersebut, bukan sekadar menganggapnya benar. Dari akun biasa tanpa sudo, jalankan:

echo test >> /var/log/auth.log
cat /var/log/audit/audit.log
auditctl -D
id -nG

Urutannya harus seperti berikut: Permission denied, karena auth.log dimiliki oleh syslog dengan grup adm dan mode 640; Permission denied lagi, karena log audit memiliki mode 600 dan dimiliki oleh root; error yang menolak eksekusi, karena perubahan aturan audit memerlukan CAP_AUDIT_CONTROL; serta daftar grup yang tidak memuat adm maupun systemd-journal.

Pemeriksaan terakhir inilah yang sering gagal. Keanggotaan adm memberikan akses baca ke /var/log/auth.log, sedangkan keanggotaan systemd-journal memberikan akses baca ke seluruh journal. Keduanya tidak memberikan akses tulis, sehingga tidak memungkinkan manipulasi. Keduanya memungkinkan seseorang membaca setiap baris autentikasi pada server. Karena itu, keputusan ini harus dibuat dengan sengaja, bukan dengan menyalin baris usermod -aG dari jawaban forum.

Terakhir, pastikan dua hal yang harus tetap berlaku setelah reboot:

sudo auditctl -s
systemctl is-enabled auditd

enabled 2 berarti kumpulan aturan dikunci hingga boot berikutnya. enabled dari perintah kedua berarti auditd kembali berjalan setelah boot tersebut. Kumpulan aturan yang hanya bertahan hingga pembaruan kernel berikutnya juga bukan jejak audit.

FAQ

Bagaimana cara melihat setiap perintah yang dijalankan pengguna tertentu?

Cari uid pengguna tersebut dengan id -u alice, lalu cari log audit berdasarkan login uid: sudo ausearch -ul 1000 -ts today -i. Tambahkan -k exec untuk membatasi hasil pada aturan execve. Login uid ditetapkan saat login dan tetap sama setelah su dan sudo -i, sehingga cara ini juga menangkap perintah yang dijalankan di dalam root shell yang dibuka oleh akun tersebut. Cara ini hanya berlaku untuk perintah yang dijalankan setelah aturan dimuat, karena audit tidak menyimpan riwayat peristiwa yang sebelumnya tidak dikonfigurasi untuk direkam. sudo aureport -k --summary -i menampilkan jumlah per aturan jika Anda ingin melihat pola data terlebih dahulu.

Dapatkah pengguna menghapus bash history untuk menyembunyikan perintah yang mereka jalankan?

Ya, dan tindakan ini tidak memerlukan privilege. ~/.bash_history dimiliki oleh pengguna tersebut dengan mode 600, sehingga pengguna dapat mengedit, mengosongkan, atau menghapusnya. Pengguna juga dapat menghentikan penulisannya dengan unset HISTFILE, menghentikan pencatatan di tengah sesi dengan set +o history, atau menyembunyikan perintah tertentu dengan mengetikkannya menggunakan spasi di awal saat HISTCONTROL=ignorespace ditetapkan. Bash menulis file tersebut saat shell keluar, sehingga sesi yang dihentikan dengan kill -9 $$ tidak mencatat apa pun. Perlakukan shell history sebagai petunjuk, bukan sebagai bukti.

Apakah sudo mencatat apa yang terjadi di dalam sudo -i?

Tidak. sudo mencatat perintah yang diminta untuk dijalankan, sehingga sudo -i menghasilkan satu baris untuk shell tersebut dan tidak mencatat apa pun setelahnya. Setiap perintah yang diketik di dalam root shell itu tidak terlihat oleh sudo karena sudo tidak lagi terlibat. sudo su -, sudo bash, dan program apa pun yang diizinkan dengan shell escape berperilaku sama. Dua hal dapat menutup celah ini: aturan audit pada execve, yang mencatat setiap program dengan login uid asli, serta aturan sudoers yang sejak awal tidak memberikan shell.

Apakah auditd akan memperlambat server saya?

Hal ini sepenuhnya bergantung pada jumlah proses yang dimulai oleh beban kerja Anda, jadi lakukan pengukuran dan jangan hanya mengandalkan suatu angka. Server yang sebagian besar hanya menangani request menjalankan exec dengan sangat sedikit dan tidak akan merasakan dampaknya. Build host atau CI runner menjalankan exec terus-menerus dan dapat merasakan dampak yang signifikan karena ketika audit backlog kernel penuh, proses yang menghasilkan peristiwa akan dijeda sampai tersedia ruang. Jalankan sudo auditctl -s di bawah beban nyata, lalu pantau backlog dan lost. Nilai lost di atas zero berarti ada record yang terhapus. Ini adalah hasil terburuk karena log kini memiliki celah yang tidak terlihat.

Di mana audit log sebaiknya disimpan?

Di mesin lain, dengan penundaan yang diukur dalam detik. Siapa pun yang memperoleh akses root pada host yang diaudit dapat menghapus /var/log/audit/audit.log dan menulis ulang /var/log/auth.log, sehingga salinan lokal hanya dapat menjawab pertanyaan tentang insiden yang tidak berusaha disembunyikan. Teruskan log dengan plugin audisp-remote ke auditd terpusat, atau aktifkan plugin audit syslog dan teruskan seluruh aliran syslog dengan rsyslog melalui TLS. Berikan kredensial khusus kepada collector, dan pastikan akun yang diaudit tidak memiliki akses ke collector tersebut.