บันทึกคำสั่งทั้งหมดที่รันโดยผู้ดูแลระบบบนเซิร์ฟเวอร์ที่ใช้งานจริง

เป็นนโยบายของ บริษัท สำหรับผู้ดูแลระบบในการเข้าสู่เซิร์ฟเวอร์ผ่านชื่อผู้ใช้ส่วนบุคคลแล้วเรียกใช้sudo -iเพื่อกลายเป็นราก เมื่อเรียกใช้sudo -isudo จะสร้างตัวแปรสภาพแวดล้อมที่เรียกว่าSUDO_USERซึ่งมีชื่อผู้ใช้ดั้งเดิมของผู้ใช้

มีวิธีการบันทึกคำสั่งทั้งหมดใน syslog ด้วยสิ่งที่คล้ายกับไวยากรณ์ต่อไปนี้:

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

รายการตัวอย่างจะเป็น:

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

เห็นได้ชัดว่ามันไม่จำเป็นต้องเป็นไวยากรณ์ข้างต้นอย่างแน่นอน แต่ก็ต้องมีผู้ใช้จริงขั้นต่ำ (เช่น root), ผู้ใช้ sudo (เช่น ksoviero) และคำสั่งทั้งหมดที่ถูกเรียกใช้ (เช่น yum ติดตั้งแบบสุ่ม -pkg)

ฉันได้ลองsnoopyไปแล้วแต่ไม่ได้รวมSUDO_USERตัวแปร

อัปเดต : มีอีก 2 สิ่งที่โผล่ขึ้นมาในความคิดเห็นและคำถามที่ตามมา:

• การใช้auditdวิธีนี้จะเพิ่มปริมาณการบันทึกของคุณอย่างมากโดยเฉพาะอย่างยิ่งหากระบบมีการใช้งานอย่างหนักผ่าน commandline ปรับนโยบายการเก็บบันทึกของคุณ
• Auditdบันทึกในโฮสต์ที่พวกเขาสร้างจะมีความปลอดภัยเท่ากับไฟล์อื่น ๆ ในกล่องเดียวกัน ส่งต่อบันทึกของคุณไปยังเซิร์ฟเวอร์รวบรวมบันทึกระยะไกลเช่น ELK หรือ Graylog เพื่อรักษาความสมบูรณ์ของบันทึกของคุณ นอกจากนี้เมื่อเพิ่มเข้าไปยังจุดด้านบนจะช่วยให้สามารถลบบันทึกเก่า ๆ ได้มากขึ้น

ตามที่ได้รับการแนะนำโดย Michael Hampton auditdเป็นเครื่องมือที่ถูกต้องสำหรับงานที่นี่

ฉันทดสอบสิ่งนี้ในการติดตั้ง Ubuntu 12.10 ดังนั้นระยะของคุณอาจแตกต่างกันไปตามระบบอื่น ๆ

• ติดตั้งauditd:

  apt-get install auditd

• เพิ่ม 2 บรรทัดเหล่านี้ไปที่/etc/audit/audit.rules:

  -a exit, เสมอ -F arch = b64 -F euid = 0 -S execve
  ออก -a เสมอ -F arch = b32 -F euid = 0 -S execve

สิ่งเหล่านี้จะติดตามคำสั่งทั้งหมดที่รันโดย root ( euid=0) ทำไมต้องมีกฎสองข้อ? execvesyscall จะต้องได้รับการติดตามทั้งในรหัส 32 และ 64 บิต

• หากต้องการกำจัดauid=4294967295ข้อความในบันทึกให้เพิ่มaudit=1cmdline ของเคอร์เนล (โดยการแก้ไข/etc/default/grub)

• วางสาย

  session required pam_loginuid.so

ในทุกไฟล์ PAM การตั้งค่าที่เกี่ยวข้องกับการเข้าสู่ระบบ ( /etc/pam.d/{login,kdm,sshd}) แต่ไม่ได้อยู่ในแฟ้มที่มีความเกี่ยวข้องกับหรือsu sudoนี้จะช่วยauditdให้ได้รับการใช้งานการโทรuidอย่างถูกต้องเมื่อเรียกหรือsudosu

• รีสตาร์ทระบบของคุณทันที

• ลองล็อกอินและเรียกใช้คำสั่งบางอย่าง:

    $ id -u
    1000
    $ sudo ls /
    bin data data dev และอื่น ๆ ในบ้าน
    $ sudo su -
    # ls / etc
    [ ... ]

สิ่งนี้จะให้สิ่งนี้ใน/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)

auidคอลัมน์มีผู้ใช้โทรศัพท์ของuidซึ่งจะช่วยให้คุณกรองสำหรับคำสั่งดำเนินการโดยผู้ใช้รายนี้ด้วย

 ausearch -ua 1000

นี่จะแสดงรายการคำสั่งที่ผู้ใช้รันในฐานะรูท

แหล่งที่มา:

• 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

จำไว้ว่า sudo นั้นบันทึกคำสั่ง sudo ทั้งหมดใน syslog ดังนั้นผู้ใช้ที่เป็นส่วนตัวทั้งหมดควรได้รับการศึกษาไม่ใช่แค่ sudo เพื่อรับรูตเชลล์ แต่ไปที่:

sudo command p1 p2 ... pn

ปัญหาเกี่ยวกับวิธีนี้หรือวิธีการใด ๆ ที่ฉันคิดคือในฐานะrootผู้ใช้มันค่อนข้างยากที่จะป้องกันผู้ใช้จากการหลีกเลี่ยงการบันทึกชนิดใด ๆ ดังนั้นทุกสิ่งที่คุณลองจะเป็น <100% ฉันขอโทษที่จะพูด

การศึกษาเอกสารการบังคับใช้และเหนือสิ่งอื่นใดคือสิ่งที่จำเป็น

ฉันเคยประสบปัญหาเดียวกันและต้องหาวิธีแก้ปัญหาที่รวดเร็วและสกปรก - ผู้ใช้ sudo แต่ละคนจะมีไฟล์ประวัติของตัวเองเมื่อพวกเขาเรียกใช้คำสั่ง sudo -i

ใน/root/.bashrcฉันเพิ่มบรรทัดต่อไปนี้ -

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

ดังนั้นผู้ใช้ทุกคนที่ sudos to root จะมีไฟล์ประวัติ. bash_history-username

วิธีอื่น -

เพิ่มรหัสต่อไปนี้/root/.bashrcและมันจะผนวกชื่อผู้ใช้ sudo-user และคำสั่งไปยังไฟล์บันทึกที่เคยมีการตั้งค่าระดับการแจ้งเตือน / var / log / ข้อความส่วนใหญ่

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

เครดิตเพื่อ - http://backdrift.org/logging-bash-history-to-syslog-using-traps

จำนวนสถานประกอบการที่จริงห้ามการใช้ auditd เพราะเป็นทรัพยากรเข้มข้นและอาจส่งผลให้โอกาสในการปฏิเสธการโจมตีบริการ

ทางออกหนึ่งคือการกำหนดค่า Korn เชลล์ล่าสุด (ksh-93 ดูที่http://kornshell.com/สำหรับรายละเอียด) เพื่อบันทึกคำสั่งทั้งหมดที่ดำเนินการเป็นรูทไปยังเซิร์ฟเวอร์ syslog ระยะไกลและจากนั้นจะต้องใช้นโยบายที่ยกเว้นในกรณีฉุกเฉิน สถานการณ์ sysadmins เข้าสู่ระบบด้วยบัญชีส่วนตัวและดำเนินการ Korn เชลล์ที่ปรับปรุงแล้วผ่าน sudo การตรวจสอบบันทึกสามารถตรวจพบได้เมื่อผู้ดูแลระบบเรียกใช้เชลล์อื่นจากเชลล์ที่อนุมัติแล้วเพื่อให้ครอบคลุมแทร็กของพวกเขาจากนั้น SA จะได้รับการศึกษาตามความจำเป็น

Sudo มีสิ่งที่เรียกว่าsudoreplayเมื่อเปิดใช้งานเซสชันแล้วและสามารถเล่นซ้ำได้ในภายหลังทำงานคล้ายกับscriptคำสั่งที่สร้างเทอร์มินัลเซสชันที่ typescript ของเทอร์มินัลที่สามารถเล่นซ้ำได้ในภายหลังด้วยscriptreplayคำสั่ง

ตั้งแต่เวอร์ชัน 2.0.0 snoopyสามารถบันทึกตัวแปรสภาพแวดล้อมตามอำเภอใจได้

อย่างไรก็ตามการสนับสนุนเมื่อเร็ว ๆ นี้ชี้ให้เห็นว่าเจ้าของบันทึกการทำงานของ tty นั้นค่อนข้างมีประสิทธิภาพและสวยงามสำหรับคำตอบของคำถาม

การเปิดเผยข้อมูล: ฉันเป็นผู้ดูแลด้อม

ไม่ใช่ว่ามีอะไรผิดปกติกับคำตอบอื่น ๆ ในตอนนี้ แต่ถ้าคุณคิดว่าsudoการบันทึกข้อมูลผ่านsyslogนั้นเป็นที่น่าพอใจฉันอาจขอแนะนำรอยย่น: บันทึกผ่านเครือข่ายไปยังโฮสต์การตรวจสอบระยะไกล

ที่ได้รับปัญหาของ "ตอนนี้ฉันกลายเป็นรากฉันสามารถลบร่องรอยของความผิดพลาดของฉันออกจากบันทึก" ตอนนี้คุณอาจเป็นรูทในกล่องโลคัล แต่คุณไม่สามารถเรียกแพ็คเก็ตบันทึกนั้นกลับมาจากเครือข่ายและคุณ (สมมุติ) ไม่มีสิทธิ์รูทในโฮสต์การตรวจสอบระยะไกล

ฉันทำสิ่งนี้กับเครือข่ายที่ฉันจัดการมานานหลายปีแล้วและมันก็มีข้อดีอีกสองประการคือ

ประการแรกมีที่เดียวในเครือข่ายที่จะไปตรวจสอบ syslogs ทั้งหมดซึ่งจะช่วยให้เกิดความสัมพันธ์ของเหตุการณ์ได้ง่ายขึ้นและเป็นร้านค้าที่ครบวงจรสำหรับการตรวจสอบเช่น "เมื่อjunoถูกบ่นว่าเซิร์ฟเวอร์ NFS heraไม่ตอบสนอง สิ่งเดียวกันในเวลาเดียวกันถ้าเป็นเช่นheraนั้นน่าจะเป็นปัญหาลองดูสิ่งที่เธอบันทึกไว้ถ้าไม่junoการเชื่อมต่อเครือข่ายของผู้ต้องสงสัยมากกว่านั้นเราจะเห็นสิ่งอื่นที่junoเข้าสู่ระบบในเวลานั้น "

ประการที่สองการหมุนบันทึก syslog ง่ายขึ้น: คุณไม่เก็บสำเนาของบันทึกไว้ในโฮสต์ในพื้นที่นานกว่าสองสามวัน แต่คุณต้องแน่ใจว่าเซิร์ฟเวอร์การตรวจสอบมีพื้นที่ดิสก์จำนวนมากและเก็บ syslogs ทั้งหมดไว้เป็นเวลาหลายปี นอกจากนี้หากคุณต้องการเขียนลงในสื่อบันทึกของ WORM เพื่อวัตถุประสงค์ในการตรวจสอบทางนิติเวชคุณต้องซื้อไดรฟ์ WORM หนึ่งไดรฟ์เท่านั้น