Cara audit arahan pengguna pada pelayan Linux

Apakah yang sebenarnya merekodkan arahan yang dijalankan oleh pengguna pada pelayan anda

Untuk mengaudit arahan yang dijalankan oleh pengguna pada pelayan anda, anda memerlukan rekod yang tidak boleh disunting oleh pengguna tersebut. Shell history bukanlah rekod sedemikian. Ia hanyalah fail kemudahan yang dimiliki oleh akaun yang menulisnya, dan sesiapa sahaja yang boleh menaip dalam shell tersebut boleh mematikannya atau memadamkannya.

Empat lapisan mampu menyimpan rekod yang sebenar, dan setiap satunya mempunyai kos tersendiri. sudo menulis satu baris bagi setiap arahan ke dalam syslog. Log I/O sudo menangkap keseluruhan sesi bagi satu akaun. Shell hook seperti PROMPT_COMMAND merekodkan apa yang ditaip oleh pengguna bash interaktif. Subsistem audit kernel merekodkan syscall execve itu sendiri, itulah sebabnya ia merupakan satu-satunya lapisan yang melihat setiap proses. Panduan ini mendaki tangga tersebut, menyatakan di mana setiap lapisan berhenti, dan berakhir dengan bahagian yang menentukan sama ada semua ini berbaloi: memindahkan rekod keluar dari mesin sebelum orang yang anda audit dapat mencapainya.

Satu amaran sebelum anda bermula. Subsistem audit adalah kerja kernel, jadi tiada satu pun daripadanya boleh diuji di dalam container yang berkongsi kernel hos. Jalankan arahan ini pada KVM VPS di mana kernel tersebut adalah milik anda.

Mengapa shell history bukan jejak audit

~/.bash_history gagal sebagai bukti atas empat sebab biasa, dan tiada satu pun daripadanya memerlukan penyerang yang bijak.

Ia milik pengguna. Fail tersebut mempunyai mod 600 dan dimiliki oleh akaun tersebut, jadi rm ~/.bash_history tidak memerlukan sebarang keistimewaan langsung. Begitu juga dengan membukanya dalam editor dan membuang dua puluh baris yang penting.

Ia ditulis apabila shell ditamatkan. Sesi yang berakhir dengan kill -9 $$, atau dengan sambungan yang terputus, tidak menulis apa-apa. history -c sebelum exit memberikan kesan yang sama dan kelihatan seolah-olah tiada apa yang berlaku.

Ia boleh dimatikan dengan satu perkataan. unset HISTFILE menghentikan penulisan fail untuk sesi tersebut. set +o history menghentikan rakaman serta-merta. HISTCONTROL=ignorespace menyembunyikan setiap arahan yang ditaip dengan ruang di hadapan. Semua ini ada dalam man bash, kerana ia bertujuan untuk berada di bawah kawalan pengguna.

Ia merekodkan apa yang ditaip, bukan apa yang dijalankan. Alias atau fungsi shell bermakna teks dalam fail tersebut bukanlah program yang dilaksanakan oleh kernel.

Tiada cap masa juga, melainkan HISTTIMEFORMAT ditetapkan semasa entri ditulis, kerana bash hanya menulis baris penanda #1755043200 apabila pemboleh ubah itu ditetapkan.

Pada log masuk yang dikongsi, ia juga tidak dapat memberitahu anda siapa pelakunya. Tiga orang yang menggunakan satu akaun deploy menghasilkan satu fail yang bercampur di bawah satu uid. Tiada lapisan pengelogan yang boleh mengaitkan tindakan kepada manusia apabila dua manusia berkongsi uid, yang merupakan hujah praktikal untuk satu akaun tanpa keistimewaan bagi setiap orang dan bukannya log masuk yang dikongsi.

Shell history bagus untuk tugas sebenarnya, iaitu membantu anda menaip semula arahan semalam. Gunakannya sebagai petunjuk. Jangan sekali-kali membentangkannya sebagai bukti.

Perkara yang direkodkan oleh sudo dan hadnya

sudo menghantar satu baris untuk setiap arahan yang dijalankan ke kemudahan authpriv syslog.

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

Setiap baris menyatakan pengguna, terminal, direktori kerja, pengguna sasaran dan arahan tersebut:

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

Jika /var/log/auth.log tidak wujud, rsyslog tidak dipasang pada imej tersebut dan rekod yang sama hanya terdapat dalam journal. Pastikan journal tidak bersifat sementara (volatile) sebelum anda bergantung kepadanya:

journalctl --list-boots

Jika hanya but semasa yang disenaraikan, ini bermakna /var/log/journal tidak wujud, jadi journal disimpan dalam /run dan setiap baris akan hilang pada but semula yang seterusnya. Jadikan ia kekal:

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

Sekarang, perhatikan hadnya. sudo merekodkan arahan yang diminta untuk dijalankan. Ia tidak merekodkan apa yang dilakukan oleh arahan tersebut selepas itu. Oleh itu, satu baris menamatkan jejak tersebut:

sudo -i

Log hanya mendapat satu rekod untuk shell tersebut. Setiap arahan yang ditaip di dalam shell root itu tidak dapat dilihat oleh sudo, kerana sudo tidak lagi berada dalam laluan (path). sudo su -, sudo bash, dan sudo vim /etc/shadow yang diikuti oleh :!bash semuanya mempunyai bentuk yang sama. Peraturan sudoers yang membenarkan sebarang program dengan shell escape, seperti vim atau find, adalah peraturan yang memberikan akses root tanpa log. Semak perkara yang sebenarnya boleh dicapai oleh sesuatu akaun sebelum anda mempercayai baris lognya:

sudo -l -U alice

Merakam sesi penuh untuk satu akaun

Cari dahulu versi sudo yang anda gunakan, kerana ciri ini tidak wujud dalam penulisan semula Rust:

sudo --version | head -1

Jika output memaparkan sudo-rs, langkau bahagian ini dan gunakan subsistem audit. Dokumentasi rasmi Ubuntu untuk keluaran 25.10 dan 26.04 menyenaraikan I/O logging dan sudoreplay sebagai tidak disokong, dan perkara ini masih benar sehingga Ogos 2026. Ini penting kerana sudo-rs merupakan sudo lalai pada keluaran tersebut, jadi naik taraf boleh membuang kawalan yang anda sangka anda miliki. Senarai penuh perubahan kelakuan sudo-rs perlu dibaca sebelum anda merancang sebarang pembalakan (logging) berasaskan sudo.

Dengan sudo asal, yang masih disertakan dalam Ubuntu 24.04 LTS, aktifkan I/O logging untuk satu akaun:

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

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

Gunakan visudo dan bukannya editor teks, kerana ia akan menolak untuk menyimpan fail yang tidak boleh diurai (parse). Fail sudoers yang rosak akan menghalang semua orang daripada menggunakan sudo. Kemudian, main semula sesi:

sudo sudoreplay -l user=deploy
sudo sudoreplay 000001

sudoreplay -l menyenaraikan sesi berserta ID masing-masing dan tidak akan memaparkan apa-apa jika log_output tidak pernah digunakan pada pengguna tersebut. Kosnya: setiap bait yang melalui terminal akan disimpan di bawah /var/log/sudo-io, jadi sesi yang verbose akan memakan ruang yang besar. Baris sudoers kedua menghalang main semula daripada merakam dirinya sendiri. Kos sebenar adalah dari segi rahsia, kerana log I/O menyimpan apa sahaja yang ditaip dan dipaparkan, termasuk kata laluan yang ditaip ke dalam prompt di dalam sesi tersebut, jadi ia memerlukan perlindungan yang sama seperti stor kata laluan. Liputannya juga terhad. Ia hanya melihat arahan yang dijalankan melalui sudo. Seseorang yang log masuk dan bekerja sepenuhnya sebagai diri sendiri tidak akan dirakam langsung.

Shell hook, dan cara tepat ia dipintas

Resipi yang sering diedarkan untuk "merekod setiap arahan" ialah hook PROMPT_COMMAND yang diletakkan ke dalam /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 memaparkan setiap prompt, jadi satu baris sampai ke syslog semasa ia ditaip dan bukannya semasa keluar, dan logger menulis melalui daemon log sistem, jadi keizinan fail pengguna sendiri tidak terlibat. Buka shell log masuk baharu dan semak dengan sudo tail -f /var/log/syslog, atau journalctl -t cmdlog -f pada imej yang tidak mempunyai rsyslog.

Kemudian ia berhenti berfungsi, melalui lima cara yang anda boleh hasilkan semula dalam masa seminit.

• Shell bukan interaktif tidak pernah memaparkan prompt. ssh you@server 'id' menjalankan arahan tersebut dan kembali, dan tiada apa-apa yang direkodkan, kerana PROMPT_COMMAND tidak pernah dinilai.
• Ia adalah satu pemboleh ubah. unset PROMPT_COMMAND melumpuhkannya untuk baki sesi tersebut dan tidak memerlukan keistimewaan.
• Fail tersebut dibaca oleh shell log masuk. bash --noprofile --norc tidak pernah memuatkan /etc/profile.d/ sama sekali.
• Ia khusus untuk bash. zsh, sh, python3 -c 'import os; os.system("id")' dan :!id di dalam vim semuanya menjalankan program yang tidak akan dilihat oleh mana-mana hook prompt bash.
• Ia merekodkan baris tersebut seperti yang ditaip, jadi alias atau fungsi masih menyembunyikan arahan yang sebenarnya dijalankan.

Gunakan shell hook sebagai kemudahan. Ia menjawab "apa yang saya jalankan pada hari Selasa lepas" untuk pengguna yang bekerjasama. Jangan biarkan senarai semak menganggapnya sebagai satu kawalan.

Subsistem audit kernel melihat setiap execve

Subsistem audit Linux, yang dipacu oleh daemon auditd, merupakan satu-satunya lapisan di sini yang tidak boleh dipintas oleh pengguna, kerana rekod dibuat di dalam kernel pada saat syscall dijalankan. Jika sesuatu proses melaksanakan atur cara, satu peristiwa akan berlaku. Shell, bahasa pengaturcaraan dan kehadiran terminal tidak memberikan sebarang perbezaan.

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

auditctl -s mencetak status daemon. enabled 1 dengan pid bukan sifar bermakna ia sedang berjalan, dan lost 0 bermakna tiada rekod yang digugurkan setakat ini. Ingat pembilang lost itu, ia akan muncul semula nanti.

auid ialah medan yang menjadikan audit berbaloi. PAM menetapkan login uid apabila sesi bermula, dan kernel membawanya pada setiap proses anak sejak saat itu. Semak milik anda:

cat /proc/self/loginuid

Sesi SSH interaktif mencetak uid anda, kerana /etc/pam.d/sshd menyertakan pam_loginuid.so. Nilai 4294967295 bermakna loginuid tidak pernah ditetapkan, yang merupakan perkara biasa bagi proses yang dimulakan oleh daemon sistem semasa but. Bahagian pentingnya ialah sudo -i tidak mengubahnya: shell root yang dibuka oleh alice masih membawa auid 1000, jadi setiap arahan di dalamnya boleh dikaitkan dengan alice. Itulah jurang yang ditinggalkan oleh sudo. Mengubah loginuid setelah ditetapkan memerlukan CAP_AUDIT_CONTROL, yang tidak dimiliki oleh pengguna biasa, dan sudo auditctl --loginuid-immutable menutupnya untuk root juga sehingga but semula yang seterusnya.

Pastikan /etc/pam.d/sshd, /etc/pam.d/login dan /etc/pam.d/cron masing-masing menyertakan pam_loginuid.so, jika tidak, peristiwa akan tiba tanpa sesiapa yang dikaitkan dengannya. Itu adalah senarai fail yang sama yang anda sentuh apabila mengeraskan akses SSH pada VPS, jadi lakukan kedua-dua tugas tersebut serentak.

Set peraturan permulaan untuk auditd

Peraturan disimpan dalam /etc/audit/rules.d/*.rules. augenrules menggabungkan peraturan tersebut mengikut susunan nama fail ke dalam satu senarai, dan susunan ini menentukan kelakuan sistem kerana kernel akan berhenti pada peraturan pertama yang sepadan. Baca kandungan sedia ada sebelum menambah apa-apa, kerana -D dalam fail yang kemudian akan memadamkan semua yang dimuatkan 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

Muatkan peraturan tersebut dan sahkan:

sudo augenrules --load
sudo auditctl -l

auditctl -l yang memaparkan semula peraturan anda bermakna peraturan tersebut sedang aktif. No rules bermakna proses pemuatan gagal, dan journalctl -u auditd -n 20 menyatakan fail serta baris yang ditolak oleh parser. Perisian audit userspace versi lama tidak memahami kata kunci unset. Jika loader memberi amaran tentang medan tersebut, tulis -F auid!=4294967295 sebagai ganti, yang merupakan nilai sama tetapi ditulis dalam bentuk penuh.

Sekarang, baca semula peristiwa:

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

-i menukarkan uid dan nombor syscall kepada nama, dan ia sebenarnya bukan pilihan. -ts recent meliputi sepuluh minit terakhir. Setiap pelaksanaan tiba sebagai sekumpulan rekod: rekod SYSCALL yang membawa uid, auid, status keluar dan key, rekod EXECVE dengan senarai argumen penuh, serta rekod CWD dan PATH untuk konteks.

Satu had yang perlu diketahui kerana ia sering memerangkap pengguna. audit merekodkan syscall, dan shell builtin tidak melakukan syscall sendiri. cd /root tidak menjalankan sebarang program. echo evil >> /etc/passwd yang ditaip pada prompt bash juga tidak menjalankan program, kerana kedua-dua echo dan redirect berlaku di dalam proses shell yang sedang berjalan. Jadi, peraturan execve melihat program dan peraturan -w melihat penulisan. Tiada satu pun yang mencukupi secara sendirian.

Akhir sekali, kunci konfigurasi:

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

-e 2 menjadikan set peraturan tidak boleh diubah sehingga but semula seterusnya. Selepas ia dimuatkan, auditctl -s akan melaporkan enabled 2, dan sebarang percubaan untuk menambah atau memadam peraturan akan gagal dengan Operation not permitted, termasuk bagi pengguna root. Tambahkan fail ini pada bahagian akhir, dan jangkakan keperluan untuk but semula setiap kali anda ingin menukar peraturan. Itulah tujuan utamanya: set peraturan yang boleh dimatikan secara senyap oleh sesiapa sahaja tidak boleh dianggap sebagai bukti.

Log audit yang tidak dibaca hanyalah artifak pematuhan

Mod kegagalan bagi auditd bukanlah kerana ia terlepas pandang sesuatu perkara. Masalahnya ialah ia merekodkan terlalu banyak perkara sehingga tiada sesiapa pun yang memeriksanya, lalu log tersebut wujud hanya untuk memenuhi senarai semak dan bukannya untuk menjawab persoalan.

Lakukan pengiraan pada pelayan anda sendiri sebelum membuat sebarang pelarasan:

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

Satu sudo apt upgrade tunggal menjalankan ribuan proses jangka pendek, dan setiap satunya membawa auid anda, jadi satu kemas kini pakej boleh melebihi jumlah aktiviti menaip manusia selama seminggu. Itulah sebabnya penindasan (suppression) di atas menamakan dpkg dan pembantunya. Lakukan penindasan mengikut fail boleh laku (executable), jangan sekali-kali mengikut pengguna: pengecualian untuk /usr/bin/dpkg merupakan satu kelompangan yang boleh anda jelaskan dalam satu ayat, manakala pengecualian untuk akaun merupakan kelompangan yang bentuknya sama persis dengan perkara yang cuba anda kesan.

Kunci -k pada setiap peraturan adalah perkara yang menjadikan log boleh dicari sebulan kemudian. ausearch -k sudoers ialah soalan yang mempunyai jawapan. ausearch tanpa penapis hanyalah dinding teks yang melatih anda untuk berhenti membaca. Jika pengumpul log anda memerlukan JSON dan bukannya format asal, laurel ialah pemalam auditd yang menulis semula setiap peristiwa sebagai satu objek JSON dengan argumen yang telah dinyahkod. Ia mendaftar dalam /etc/audit/plugins.d/ seperti pemalam lain, dan auditd akan mengambil perubahan pemalam pada sudo pkill -HUP auditd.

Kos sebenar auditd

Setiap syscall yang sepadan menjadi rekod yang diformatkan oleh kernel dan diserahkan kepada userspace. Kosnya tertumpu pada dua aspek, dan kedua-duanya boleh diukur berdasarkan beban kerja anda sendiri, bukannya sekadar meneka daripada angka yang diterbitkan oleh pihak lain.

• CPU dan kependaman (latency). Mesin yang kerap melakukan fork, seperti hos binaan atau runner CI, menghasilkan satu rekod bagi setiap exec. Apabila backlog kernel penuh, --backlog_wait_time akan menyebabkan kernel menghentikan proses yang menjana peristiwa tersebut sehingga terdapat ruang, jadi audit akan kelihatan sebagai binaan yang perlahan dan bukannya sebagai peratusan CPU. Pantau backlog dan lost dalam sudo auditctl -s di bawah beban sebenar. Nilai lost yang meningkat bermakna rekod telah digugurkan, dan log yang mempunyai jurang senyap adalah lebih buruk daripada tiada log, kerana anda masih akan mempercayainya.
• Cakera. Baca /etc/audit/auditd.conf dan tentukan dengan sengaja apa yang berlaku apabila cakera penuh, kerana nilai lalai hanyalah pendapat. max_log_file, num_logs dan max_log_file_action mengawal putaran (rotation). space_left_action, admin_space_left_action dan disk_full_action mengawal kecemasan, dan beberapa tindakan yang tersedia, antaranya halt dan single, akan mematikan mesin daripada kehilangan rekod.

Baris -f dalam /etc/audit/rules.d/audit.rules adalah keputusan yang sama pada peringkat kernel: -f 1 melaporkan kegagalan audit ke syslog, dan -f 2 menyebabkan kernel panik. Pilih 2 hanya jika anda benar-benar lebih rela kehilangan pelayan daripada kehilangan rekod. Pada VPS yang menjalankan sesuatu yang penting, lakukan putaran sebaliknya, dan pindahkan masalah storan keluar dari mesin tersebut.

Hantar log keluar dari pelayan, dalam masa hampir nyata

Ini adalah bahagian yang sering dibuktikan oleh laporan insiden. Log yang kekal pada hos yang diceroboh boleh disunting oleh sesiapa sahaja yang mencerobohnya. Root boleh menulis semula /var/log/auth.log, memadam /var/log/audit/audit.log, dan menghentikan daemon tersebut. -e 2 menghalang peraturan daripada dinyahmuat. Ia tidak melakukan apa-apa terhadap rm. Setiap lapisan di atas hanya menghasilkan bukti jika salinan keluar dari mesin itu terlebih dahulu.

Pengangkutan bagi audit itu sendiri ialah pemalam audisp-remote daripada audispd-plugins. Hidupkannya dalam /etc/audit/plugins.d/au-remote.conf:

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

Semak path berbanding command -v audisp-remote sebelum anda memuat semula, kerana laluan yang salah tidak akan menghasilkan apa-apa kecuali satu baris dalam jurnal. Tetapkan remote_server dan port dalam /etc/audit/audisp-remote.conf, dan pada pengumpul (collector) tetapkan tcp_listen_port = 60 dalam auditd.conf miliknya sendiri. Muat semula dengan sudo pkill -HUP auditd. Pada banyak imej, systemctl restart auditd ditolak kerana fail unit menetapkan RefuseManualStop=yes, jadi isyarat (signal) adalah laluan yang boleh dipercayai.

Pilihan lain meletakkan audit ke dalam aliran syslog yang anda sudah majukan. /etc/audit/plugins.d/syslog.conf disertakan dengan active = no. Tetapkannya kepada yes, muat semula, dan peristiwa audit akan bergabung dengan baris sudo serta segala yang lain. Kemudian majukan kesemuanya dengan rsyslog melalui TLS (transport layer security), yang memerlukan pakej 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")

Tetapan baris gilir (queue) adalah bahagian yang menarik. action.resumeRetryCount="-1" mencuba semula selama-lamanya, dan baris gilir bantuan cakera dengan queue.saveOnShutdown="on" menyimpan rekod semasa pengumpul tidak dapat dicapai, kemudian menghantarnya apabila ia kembali aktif. Tanpa kedua-duanya, but semula pengumpul akan meninggalkan lubang dalam bukti anda dan tiada apa-apa yang memberitahu anda bahawa lubang itu wujud. Gunakan dengan sudo systemctl restart rsyslog, kemudian sahkan rekod benar-benar sampai pada pengumpul sebelum anda mempercayai mana-mana daripadanya.

Satu gelung perlu ditutup: pengumpul mestilah mesin yang tidak boleh dilog masuk oleh orang yang diaudit. Jika kumpulan pentadbir yang sama memegang root pada pelayan log, anda hanya menyalin fail tersebut, bukan melindunginya. Asingkan kelayakan, asingkan kunci, dan sebaik-baiknya asingkan akaun pembekal. Ini adalah penaakulan yang sama yang menjadikan cara berpusat untuk mengurus banyak pelayan Linux berbaloi untuk dibina sebelum anda memerlukannya, dan ia adalah perbezaan antara jam pertama yang berguna dan tidak berguna apabila anda sedang menangani VPS yang diceroboh.

Pastikan pengguna biasa tidak boleh menulis semula rekod

Uji tuntutan tersebut dan jangan sekadar membuat andaian. Daripada akaun biasa, tanpa sudo:

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

Jangkakan, mengikut urutan: Permission denied, kerana auth.log dimiliki oleh syslog dengan kumpulan adm dan mod 640; Permission denied sekali lagi, kerana log audit mempunyai mod 600 dan dimiliki oleh root; ralat yang menolak untuk dijalankan, kerana menukar peraturan audit memerlukan CAP_AUDIT_CONTROL; dan senarai kumpulan yang tidak mengandungi adm mahupun systemd-journal.

Semakan terakhir itu adalah perkara yang sering gagal dilakukan oleh pengguna. Keahlian dalam adm memberikan akses baca kepada /var/log/auth.log, dan keahlian dalam systemd-journal memberikan akses baca kepada keseluruhan jurnal. Tiada satu pun yang memberikan akses tulis, jadi tiada satu pun yang membenarkan pengubahan data. Kedua-duanya membenarkan seseorang membaca setiap baris pengesahan pada kotak tersebut, yang merupakan keputusan yang perlu dibuat dengan sengaja dan bukannya dengan menyalin baris usermod -aG daripada jawapan forum.

Akhir sekali, sahkan dua perkara yang mesti kekal selepas but semula:

sudo auditctl -s
systemctl is-enabled auditd

enabled 2 bermaksud set peraturan dikunci sehingga but seterusnya. enabled daripada arahan kedua bermaksud auditd bermula semula selepas but tersebut. Set peraturan yang hanya bertahan sehingga kemas kini kernel seterusnya bukanlah jejak audit.

FAQ

Bagaimanakah cara untuk melihat setiap arahan yang dijalankan oleh pengguna tertentu?

Cari uid mereka dengan id -u alice, kemudian cari log audit mengikut login uid: sudo ausearch -ul 1000 -ts today -i. Tambahkan -k exec untuk mengehadkannya kepada peraturan execve. Login uid ditetapkan semasa log masuk dan kekal merentasi su dan sudo -i, jadi ini dapat mengesan arahan yang dijalankan di dalam shell root yang dibuka oleh akaun tersebut. Ia hanya berfungsi untuk arahan yang dilaksanakan selepas peraturan dimuatkan, kerana audit tidak menyimpan sejarah peristiwa yang tidak dikonfigurasikan untuk direkodkan. sudo aureport -k --summary -i memberikan anda kiraan bagi setiap peraturan jika anda ingin melihat bentuk data tersebut terlebih dahulu.

Bolehkah pengguna memadam sejarah bash mereka untuk menyembunyikan apa yang telah dijalankan?

Ya, dan ia tidak memerlukan keistimewaan. ~/.bash_history dimiliki oleh pengguna tersebut dengan mod 600, jadi mereka boleh menyunting, memotong, atau memadamnya. Mereka juga boleh menghentikan penulisannya dengan unset HISTFILE, menghentikan rakaman di pertengahan sesi dengan set +o history, atau menyembunyikan arahan tunggal dengan menaipnya bermula dengan ruang kosong apabila HISTCONTROL=ignorespace ditetapkan. Bash menulis fail tersebut apabila shell ditutup, jadi sesi yang dimatikan dengan kill -9 $$ tidak merekodkan apa-apa. Anggap sejarah shell sebagai petunjuk, bukan sebagai bukti.

Adakah sudo merekodkan apa yang berlaku di dalam sudo -i?

Tidak. sudo merekodkan arahan yang diminta untuk dijalankan, jadi sudo -i menghasilkan satu baris untuk shell dan tiada apa-apa selepas itu. Setiap arahan yang ditaip dalam shell root tersebut tidak dapat dilihat oleh sudo, kerana sudo tidak lagi terlibat. sudo su -, sudo bash, dan mana-mana program yang dibenarkan dengan shell escape berkelakuan dengan cara yang sama. Dua perkara menutup jurang ini: peraturan audit pada execve, yang merekodkan setiap program dengan login uid asal dilampirkan, dan peraturan sudoers yang tidak memberikan shell sejak awal lagi.

Adakah auditd akan melambatkan pelayan saya?

Ia bergantung sepenuhnya kepada berapa banyak proses yang dimulakan oleh beban kerja anda, jadi ukurlah ia dan jangan hanya mempercayai angka. Pelayan yang kebanyakannya menjawab permintaan hanya melaksanakan sedikit proses dan tidak akan merasai perbezaannya. Pelayan binaan atau CI runner melaksanakan proses secara berterusan dan mungkin merasai kesannya, kerana apabila backlog audit kernel penuh, proses yang menjana peristiwa tersebut akan dijeda sehingga terdapat ruang. Jalankan sudo auditctl -s di bawah beban sebenar dan perhatikan backlog dan lost. Sebarang lost melebihi sifar bermakna rekod telah digugurkan, yang merupakan hasil paling buruk, kerana log kini mempunyai jurang yang tidak kelihatan.

Di manakah log audit harus disimpan?

Pada mesin lain, dengan kelewatan yang diukur dalam saat. Sesiapa yang mencapai tahap root pada hos yang diaudit boleh memadam /var/log/audit/audit.log dan menulis semula /var/log/auth.log, jadi salinan tempatan hanya menjawab soalan mengenai insiden yang tidak cuba disembunyikan oleh sesiapa. Majukan dengan pemalam audisp-remote ke auditd pusat, atau aktifkan pemalam audit syslog dan majukan keseluruhan aliran syslog dengan rsyslog melalui TLS. Berikan pengumpul (collector) kelayakan tersendiri, dan pastikan akaun yang diaudit tidak mempunyai akses kepadanya.