Catat semua perintah yang dijalankan oleh admin di server produksi

Ini adalah kebijakan perusahaan untuk admin untuk masuk ke server melalui nama pengguna pribadi, dan kemudian jalankan sudo -iuntuk menjadi root. Saat berjalan sudo -i, sudo akan membuat variabel lingkungan bernama SUDO_USER, yang berisi nama pengguna pengguna asli.

Apakah ada cara untuk mencatat SEMUA perintah dalam syslog dengan sesuatu yang mirip dengan sintaks berikut:

${TIME/DATE STAMP}: [${REAL_USER}|${SUDO_USER}]: ${CMD}

Contoh entri adalah:

Sat Jan 19 22:28:46 CST 2013: [root|ksoviero]: yum install random-pkg

Jelas itu tidak harus persis sintaks di atas, hanya harus menyertakan minimal pengguna nyata (mis. Root), pengguna sudo (mis. Ksoviero), dan perintah lengkap yang dijalankan (mis. Yum instal acak-pkg).

Saya sudah mencoba snoopy, tetapi tidak termasuk SUDO_USERvariabel.

Pembaruan : 2 hal lagi yang muncul di komentar dan pertanyaan lanjutan:

• Menggunakan auditdcara ini akan secara dramatis meningkatkan volume log Anda, terutama jika sistem ini banyak digunakan melalui commandline. Sesuaikan kebijakan penyimpanan log Anda.
• Auditdlog pada host tempat mereka dibuat sama amannya dengan file lain pada kotak yang sama. Teruskan log Anda ke server pengumpulan log jarak jauh seperti ELK atau Graylog untuk menjaga integritas log Anda. Plus, menambahkan ke titik di atas, memungkinkan untuk lebih agresif menghapus log lama.

Seperti yang disarankan oleh Michael Hampton, auditdadalah alat yang tepat untuk pekerjaan di sini.

Saya menguji ini pada instalasi Ubuntu 12.10, jadi jarak tempuh Anda mungkin berbeda pada sistem lain.

• Pasang auditd:

  apt-get install auditd

• Tambahkan 2 baris ini ke /etc/audit/audit.rules:

  -Sebuah exit, selalu -F arch = b64 -F euid = 0 -S execve
  -sebuah exit, selalu -F arch = b32 -F euid = 0 -S execve

Ini akan melacak semua perintah yang dijalankan oleh root ( euid=0). Mengapa ada dua aturan? The execvesyscall harus dilacak di kedua 32 dan 64 bit kode.

• Untuk menghilangkan auid=4294967295pesan dalam log, tambahkan audit=1ke cmdline kernel (dengan mengedit /etc/default/grub)

• Tempatkan garis

  session required pam_loginuid.so

di semua file konfigurasi PAM yang relevan dengan login ( /etc/pam.d/{login,kdm,sshd}), tetapi tidak dalam file yang relevan dengan suatau sudo. Ini akan memungkinkan auditdpengguna mendapatkan panggilan uiddengan benar saat menelepon sudoatau su.

• Mulai ulang sistem Anda sekarang.

• Mari masuk dan menjalankan beberapa perintah:

    $ id -u
    1000
    $ sudo ls /
    bin boot data dev dll home initrd.img initrd.img.old lib lib32 lib64 hilang + ditemukan media mnt opt ​​proc root run sbin awal selinux srv sys tmp usr var vmlinuz vmlinuz.old
    $ sudo su -
    # ls / etc
    [...]

Ini akan menghasilkan sesuatu seperti ini di /var/log/audit/auditd.log:

----
time->Mon Feb  4 09:57:06 2013
type=PATH msg=audit(1359968226.239:576): item=1 name=(null) inode=668682 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1359968226.239:576): item=0 name="/bin/ls" inode=2117 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=CWD msg=audit(1359968226.239:576):  cwd="/home/user"
type=EXECVE msg=audit(1359968226.239:576): argc=2 a0="ls" a1="/"
type=SYSCALL msg=audit(1359968226.239:576): arch=c000003e syscall=59 success=yes exit=0 a0=10cfc48 a1=10d07c8 a2=10d5750 a3=7fff2eb2d1f0 items=2 ppid=26569 pid=26570 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="ls" exe="/bin/ls" key=(null)
----
time->Mon Feb  4 09:57:06 2013
type=PATH msg=audit(1359968226.231:575): item=1 name=(null) inode=668682 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1359968226.231:575): item=0 name="/usr/bin/sudo" inode=530900 dev=08:01 mode=0104755 ouid=0 ogid=0 rdev=00:00
type=CWD msg=audit(1359968226.231:575):  cwd="/home/user"
type=BPRM_FCAPS msg=audit(1359968226.231:575): fver=0 fp=0000000000000000 fi=0000000000000000 fe=0 old_pp=0000000000000000 old_pi=0000000000000000 old_pe=0000000000000000 new_pp=ffffffffffffffff new_pi=0000000000000000 new_pe=ffffffffffffffff
type=EXECVE msg=audit(1359968226.231:575): argc=3 a0="sudo" a1="ls" a2="/"
type=SYSCALL msg=audit(1359968226.231:575): arch=c000003e syscall=59 success=yes exit=0 a0=7fff327ecab0 a1=7fd330e1b958 a2=17cc8d0 a3=7fff327ec670 items=2 ppid=3933 pid=26569 auid=1000 uid=1000 gid=1000 euid=0 suid=0 fsuid=0 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=1 comm="sudo" exe="/usr/bin/sudo" key=(null)
----
time->Mon Feb  4 09:57:09 2013
type=PATH msg=audit(1359968229.523:578): item=1 name=(null) inode=668682 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1359968229.523:578): item=0 name="/bin/su" inode=44 dev=08:01 mode=0104755 ouid=0 ogid=0 rdev=00:00
type=CWD msg=audit(1359968229.523:578):  cwd="/home/user"
type=EXECVE msg=audit(1359968229.523:578): argc=2 a0="su" a1="-"
type=SYSCALL msg=audit(1359968229.523:578): arch=c000003e syscall=59 success=yes exit=0 a0=1ceec48 a1=1cef7c8 a2=1cf4750 a3=7fff083bd920 items=2 ppid=26611 pid=26612 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="su" exe="/bin/su" key=(null)
----
time->Mon Feb  4 09:57:09 2013
type=PATH msg=audit(1359968229.519:577): item=1 name=(null) inode=668682 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1359968229.519:577): item=0 name="/usr/bin/sudo" inode=530900 dev=08:01 mode=0104755 ouid=0 ogid=0 rdev=00:00
type=CWD msg=audit(1359968229.519:577):  cwd="/home/user"
type=BPRM_FCAPS msg=audit(1359968229.519:577): fver=0 fp=0000000000000000 fi=0000000000000000 fe=0 old_pp=0000000000000000 old_pi=0000000000000000 old_pe=0000000000000000 new_pp=ffffffffffffffff new_pi=0000000000000000 new_pe=ffffffffffffffff
type=EXECVE msg=audit(1359968229.519:577): argc=3 a0="sudo" a1="su" a2="-"
type=SYSCALL msg=audit(1359968229.519:577): arch=c000003e syscall=59 success=yes exit=0 a0=7fff327ecab0 a1=7fd330e1b958 a2=17cc8d0 a3=7fff327ec670 items=2 ppid=3933 pid=26611 auid=1000 uid=1000 gid=1000 euid=0 suid=0 fsuid=0 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=1 comm="sudo" exe="/usr/bin/sudo" key=(null)
----
time->Mon Feb  4 09:57:09 2013
type=PATH msg=audit(1359968229.543:585): item=1 name=(null) inode=668682 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1359968229.543:585): item=0 name="/bin/bash" inode=6941 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=CWD msg=audit(1359968229.543:585):  cwd="/root"
type=EXECVE msg=audit(1359968229.543:585): argc=1 a0="-su"
type=SYSCALL msg=audit(1359968229.543:585): arch=c000003e syscall=59 success=yes exit=0 a0=13695a0 a1=7fffce08a3e0 a2=135a030 a3=7fffce08c200 items=2 ppid=26612 pid=26622 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="bash" exe="/bin/bash" key=(null)
----
time->Mon Feb  4 09:57:11 2013
type=PATH msg=audit(1359968231.663:594): item=1 name=(null) inode=668682 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1359968231.663:594): item=0 name="/bin/ls" inode=2117 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=CWD msg=audit(1359968231.663:594):  cwd="/root"
type=EXECVE msg=audit(1359968231.663:594): argc=3 a0="ls" a1="--color=auto" a2="/etc"
type=SYSCALL msg=audit(1359968231.663:594): arch=c000003e syscall=59 success=yes exit=0 a0=7fff8c709950 a1=7f91a12149d8 a2=1194c50 a3=7fff8c709510 items=2 ppid=26622 pid=26661 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="ls" exe="/bin/ls" key=(null)

The auidkolom berisi panggilan pengguna uid, yang memungkinkan Anda menyaring untuk perintah dijalankan oleh pengguna ini dengan

 ausearch -ua 1000

Ini bahkan akan mencantumkan perintah yang dijalankan pengguna sebagai root.

Sumber:

• http://www.woitasen.com.ar/2011/11/auditing-user-actions-after-sudo/
• http://linux.die.net/man/8/pam_loginuid
• http://linux.die.net/man/8/auditd

Ingat bahwa sudo sendiri mencatat semua perintah sudo di syslog, jadi semua pengguna prived harus dididik untuk tidak hanya sudo untuk mendapatkan shell root tetapi untuk:

sudo command p1 p2 ... pn

Masalah dengan ini atau pendekatan apa pun yang saya pikirkan adalah bahwa sebagai rootpengguna, cukup sulit untuk mencegah pengguna menghindari jenis logging tertentu. Jadi apapun yang Anda coba akan <100% saya minta maaf untuk mengatakan.

Pendidikan, dokumentasi, penegakan, dan di atas semua kepercayaan itulah yang diperlukan.

Saya pernah dihadapkan dengan masalah yang sama dan harus datang dengan solusi cepat dan kotor - setiap pengguna sudo akan memiliki file sejarah mereka sendiri setelah mereka menjalankan perintah sudo -i

Di /root/.bashrcsaya menambahkan baris berikut -

 export HISTFILE=/root/.bash_history-$SUDO_USER
 export HISTTIMEFORMAT="%F %T "

Jadi setiap pengguna yang sudo untuk di-rooting akan memiliki file histori .bash_history-username.

Metode lain -

Tambahkan kode berikut ke /root/.bashrcdan itu akan menambahkan nama pengguna, pengguna-sudo, dan perintah ke file log, di mana tingkat pemberitahuan diatur, kemungkinan besar / var / log / pesan.

function log2syslog
{
   declare COMMAND
   COMMAND=$(fc -ln -0)
   logger -p local1.notice -t bash -i -- "${USER}:${SUDO_USER}:${COMMAND}"
}
trap log2syslog DEBUG

Kredit untuk - http://backdrift.org/logging-bash-history-to-syslog-using-traps

Sejumlah perusahaan sebenarnya melarang penggunaan auditd karena padat sumber daya dan dapat menghasilkan peluang untuk penolakan serangan layanan.

Salah satu solusinya adalah mengonfigurasi shell Korn terbaru (ksh-93, lihat http://kornshell.com/ untuk detailnya) untuk mencatat semua perintah yang dijalankan sebagai root ke server syslog jarak jauh, dan kemudian mensyaratkan oleh kebijakan itu, kecuali dalam keadaan darurat. situasi, sysadmin masuk dengan akun pribadi dan jalankan cangkang Korn yang disempurnakan melalui sudo. Pemeriksaan log dapat mendeteksi ketika admin meluncurkan shell lain dari shell yang disetujui untuk menutupi jejak mereka, dan SA kemudian dapat dididik sesuai kebutuhan.

Sudo memiliki sesuatu yang disebut sudoreplay ketika sesi yang diaktifkan dicatat dan dapat diputar ulang nanti, berfungsi sama seperti scriptperintah yang membuat naskah sesi terminal yang kemudian dapat diputar ulang dengan scriptreplayperintah.

Bukan berarti ada yang salah dengan jawaban lain sejauh ini, tetapi jika Anda memutuskan bahwa sudologging melalui syslogmemuaskan, bolehkah saya menyarankan kerutan: log melalui jaringan ke host audit jarak jauh.

Itu mengatasi masalah "sekarang saya telah menjadi root, saya dapat menghapus jejak kesalahan saya dari log". Anda sekarang dapat melakukan root pada kotak lokal, tetapi Anda tidak dapat memanggil paket log itu kembali dari jaringan, dan Anda (mungkin) tidak memiliki hak akses root pada host audit jarak jauh.

Saya telah melakukan ini dengan beberapa jaringan yang saya kelola selama bertahun-tahun, dan ia memiliki dua keunggulan sinyal lainnya:

Pertama, ada satu tempat di jaringan untuk memeriksa semua syslog, yang memungkinkan korelasi insiden yang jauh lebih mudah, dan begitu juga toko serba ada untuk penyelidikan seperti "Ketika junomengeluh bahwa server NFS heratidak merespons, apakah ada orang lain yang mengeluh tentang hal yang sama pada saat yang sama? Jika demikian, herakemungkinan akan menjadi masalah, mari kita lihat apa yang dia login; jika tidak, junokoneksi jaringan lebih mencurigakan, mari kita lihat apa lagi yang junologin pada waktu itu. "

Kedua, rotasi log syslog menjadi lebih mudah: Anda tidak menyimpan salinan log di host lokal selama lebih dari beberapa hari, tetapi Anda memastikan server audit memiliki ruang disk yang sangat besar, dan menyimpan semua syslog di sana selama beberapa tahun. Plus, jika Anda ingin menulisnya ke media WORM untuk keperluan audit forensik misalnya, Anda hanya perlu membeli satu drive WORM.

Karena versi 2.0.0 snoopy dapat mencatat variabel lingkungan sewenang-wenang.

Namun, kontribusi baru-baru ini menunjukkan bahwa pemilik logging dari tty adalah jawaban yang cukup efektif dan elegan untuk pertanyaan "Siapa yang menjalankan perintah itu, sebagai root?".

Pengungkapan: Saya pengelola snoopy.