Đăng nhập tất cả các lệnh được chạy bởi quản trị viên trên các máy chủ sản xuất

Chính sách của công ty là quản trị viên đăng nhập vào máy chủ thông qua tên người dùng cá nhân và sau đó chạy sudo -iđể trở thành root. Khi chạy sudo -i, sudo sẽ tạo một biến môi trường được gọi SUDO_USER, chứa tên người dùng ban đầu.

Có cách nào để ghi nhật ký TẤT CẢ các lệnh trong syslog với một cái gì đó giống với cú pháp sau:

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

Một mục ví dụ sẽ là:

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

Rõ ràng là nó không phải chính xác cú pháp trên, nó chỉ phải bao gồm tối thiểu người dùng thực (ví dụ: root), người dùng sudo (ví dụ: ksoviero) và lệnh đầy đủ đã được chạy (ví dụ: yum cài đặt ngẫu nhiên-pkg).

Tôi đã thử snoopy, nhưng nó không bao gồm SUDO_USERbiến.

Cập nhật : 2 điều nữa đã xuất hiện trong các bình luận và trong các câu hỏi tiếp theo:

• Sử dụng auditdcách này sẽ tăng đáng kể khối lượng nhật ký của bạn, đặc biệt nếu hệ thống được sử dụng nhiều thông qua dòng lệnh. Điều chỉnh chính sách lưu giữ nhật ký của bạn.
• Auditdcác bản ghi trên máy chủ nơi chúng được tạo cũng an toàn như các tệp khác trên cùng một hộp. Chuyển tiếp nhật ký của bạn đến một máy chủ thu thập nhật ký từ xa như ELK hoặc Graylog để bảo vệ tính toàn vẹn của nhật ký của bạn. Thêm vào đó, thêm vào điểm trên, nó cho phép xóa mạnh hơn các bản ghi cũ.

Theo đề xuất của Michael Hampton, auditdlà công cụ chính xác cho công việc ở đây.

Tôi đã thử nghiệm điều này trên bản cài đặt Ubuntu 12.10, vì vậy số dặm của bạn có thể thay đổi trên các hệ thống khác.

• Cài đặt auditd:

  apt-get install auditd

• Thêm 2 dòng này vào /etc/audit/audit.rules:

  -a thoát, luôn luôn -F arch = b64 -F euid = 0 -S thực thi
  -a thoát, luôn luôn -F arch = b32 -F euid = 0 -S thực thi

Chúng sẽ theo dõi tất cả các lệnh được chạy bởi root ( euid=0). Tại sao hai quy tắc? Tòa nhà execvephải được theo dõi trong cả mã 32 và 64 bit.

• Để loại bỏ các auid=4294967295thông điệp trong nhật ký, hãy thêm audit=1vào cmdline của kernel (bằng cách chỉnh sửa /etc/default/grub)

• Đặt dòng

  session required pam_loginuid.so

trong tất cả các tệp cấu hình PAM có liên quan đến login ( /etc/pam.d/{login,kdm,sshd}), nhưng không phải trong các tệp có liên quan đến suhoặc sudo. Điều này sẽ cho phép auditdngười dùng gọi uidchính xác khi gọi sudohoặc su.

• Khởi động lại hệ thống của bạn bây giờ.

• Hãy đăng nhập và chạy một số lệnh:

    $ id -u
    1000
    $ sudo ls /
    bin boot data dev vv home initrd.img initrd.img.old lib lib32 lib64 bị mất + tìm thấy phương tiện mnt opt ​​Proc root run sbin scratch selinux srv sys tmp usr var vmlinuz vmlinuz.old
    $ sudo su -
    # ls / v.v
    [...]

Điều này sẽ mang lại một cái gì đó như thế này trong /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)

Các auidcột chứa người dùng gọi điện thoại của uid, cho phép bạn lọc cho các lệnh chạy của thành viên này với

 ausearch -ua 1000

Điều này thậm chí sẽ liệt kê các lệnh người dùng đã chạy như root.

Nguồn:

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

Hãy nhớ rằng chính sudo ghi lại tất cả các lệnh sudo trong syslog, vì vậy tất cả người dùng của tư nhân nên được giáo dục không chỉ đơn giản là sudo để lấy shell root mà là:

sudo command p1 p2 ... pn

Vấn đề với cách tiếp cận này hoặc bất kỳ cách tiếp cận nào tôi nghĩ đến là với tư cách là rootngười dùng, khá khó khăn để ngăn người dùng trốn tránh bất kỳ loại ghi nhật ký cụ thể nào. Do đó, bất cứ điều gì bạn thử sẽ <100% tôi rất tiếc phải nói.

Giáo dục, tài liệu, thực thi và trên hết là sự tin tưởng là những gì cần thiết.

Tôi đã từng phải đối mặt với cùng một vấn đề và phải đưa ra một giải pháp nhanh chóng và bẩn thỉu - mỗi người dùng sudo sẽ có tệp lịch sử của riêng họ sau khi họ chạy lệnh sudo -i

Trong /root/.bashrctôi đã thêm dòng sau -

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

Vì vậy, mỗi người dùng sudos để root sẽ có tệp lịch sử .bash_history-username.

Một phương pháp khác -

Thêm mã sau vào /root/.bashrcvà nó sẽ nối thêm tên người dùng, người dùng sudo và lệnh vào tệp nhật ký, khi mức độ thông báo được đặt, rất có thể là / var / log / message.

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

Tín dụng cho - http://backdrift.org/logging-bash-history-to-syslog-USE-traps

Một số cơ sở thực sự cấm sử dụng audd vì nó sử dụng nhiều tài nguyên và có thể dẫn đến cơ hội từ chối các cuộc tấn công dịch vụ.

Một giải pháp là cấu hình shell Korn mới nhất (ksh-93, xem http://kornshell.com/ để biết chi tiết) để ghi nhật ký tất cả các lệnh được thực thi dưới dạng root vào máy chủ syslog từ xa, sau đó yêu cầu chính sách, ngoại trừ trong trường hợp khẩn cấp tình huống, sysadins đăng nhập bằng tài khoản cá nhân và thực thi trình bao Korn nâng cao thông qua sudo. Kiểm tra nhật ký có thể phát hiện khi quản trị viên khởi chạy một trình bao khác từ trình bao được phê duyệt để che dấu vết của họ và SA sau đó có thể được giáo dục khi cần thiết.

Sudo có một thứ gọi là sudoreplay khi các phiên kích hoạt được ghi lại và có thể được phát lại sau đó, hoạt động tương tự như scriptlệnh tạo ra một bản thảo của phiên cuối mà sau đó có thể được phát lại bằng scriptreplaylệnh.

Không có gì sai với bất kỳ câu trả lời nào khác cho đến nay, nhưng nếu bạn quyết định rằng việc sudođăng nhập thông qua sysloglà thỏa đáng, tôi có thể đề xuất một nếp nhăn: đăng nhập qua mạng đến máy chủ kiểm toán từ xa.

Điều đó xoay quanh vấn đề "bây giờ tôi đã trở thành root, tôi có thể xóa bất kỳ dấu vết nào của sự cố của tôi khỏi nhật ký". Bây giờ bạn có thể đã root trên hộp cục bộ, nhưng bạn không thể gọi lại gói nhật ký đó từ mạng và bạn (có lẽ) không có quyền root trên máy chủ kiểm toán từ xa.

Tôi đã làm điều này với một số mạng mà tôi quản lý trong nhiều năm và nó có hai lợi thế tín hiệu khác:

Đầu tiên, có một nơi trên mạng để kiểm tra tất cả các nhật ký hệ thống, cho phép tương quan các sự cố dễ dàng hơn nhiều, và vì vậy, một cửa hàng cho các cuộc điều tra như "Khi junophàn nàn rằng máy chủ NFS herakhông phản hồi, có ai khác phàn nàn về heraCó phải đó là vấn đề cùng một lúc? Nếu vậy, rất có thể là vấn đề, hãy xem những gì cô ấy đã đăng nhập; nếu không, junokết nối mạng của nó đáng ngờ hơn, hãy xem những gì khác junođã đăng nhập vào thời điểm đó. "

Thứ hai, xoay vòng nhật ký nhật ký hệ thống trở nên dễ dàng hơn: bạn không giữ các bản sao nhật ký trên máy chủ cục bộ trong hơn một vài ngày, nhưng bạn đảm bảo rằng máy chủ kiểm toán có dung lượng đĩa rất lớn và giữ tất cả các nhật ký hệ thống ở đó trong vài năm. Ngoài ra, nếu bạn muốn viết chúng cho phương tiện WORM, ví dụ như mục đích kiểm toán pháp y, bạn chỉ phải mua một ổ WORM.

Kể từ phiên bản 2.0.0 snoopy có thể đăng nhập biến môi trường tùy ý.

Tuy nhiên, đóng góp gần đây đã chỉ ra rằng chủ sở hữu đăng nhập của tty là câu trả lời khá hiệu quả và tao nhã cho câu hỏi "Ai thực hiện lệnh đó, với tư cách là root?".

Tiết lộ: Tôi là người duy trì snoopy.