Реєструйте всі команди, якими керують адміністратори на виробничих серверах

Це адміністративна політика компанії для входу на сервери за допомогою особистого імені користувача, а потім запуску, sudo -iщоб стати root. Після запуску 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 встановити довільно-кг).

Я вже намагався snoopy, але SUDO_USERзмінна не включала .

Оновлення : ще 2 речі, які з’явились у коментарях та в наступних питаннях:

• Використання auditdцього способу значно збільшить об'єм журналу, особливо якщо система сильно використовується за допомогою командного рядка. Відкоригуйте політику збереження журналу.
• Auditdжурнали на хості, де вони створені, настільки ж безпечні, як і інші файли в тому ж полі. Пересилайте свої журнали на віддалений сервер колекції журналів, наприклад ELK або Graylog, щоб зберегти цілісність ваших журналів. Плюс до цього, додавши до пункту вище, це дозволяє більш агресивно видаляти старі журнали.

Як запропонував Майкл Хемптон, auditdце правильний інструмент для роботи тут.

Я перевірив це на установці Ubuntu 12.10, тому ваш пробіг може відрізнятися в інших системах.

• Встановити auditd:

  apt-get install auditd

• Додайте ці 2 рядки до /etc/audit/audit.rules:

  -вихід, завжди -F арка = b64 -F euid = 0 -S execve
  -вихід, завжди -F арка = b32 -F euid = 0 -S execve

Вони будуть відслідковувати всі команди, виконані root ( euid=0). Чому два правила? execveСистемний виклик повинен бути відслідковані в обох 32 і 64 бітного коду.

• Щоб позбутися auid=4294967295повідомлень у журналах, додайте audit=1до cmdline ядра (редагуючи /etc/default/grub)

• Розмістіть лінію

  session required pam_loginuid.so

у всіх файлах конфігурації PAM, які мають відношення до входу ( /etc/pam.d/{login,kdm,sshd}), але не у файлах, що стосуються suабо sudo. Це дозволить auditdотримати покликання користувача uidправильно при виклику sudoабо su.

• Перезавантажте систему зараз.

• Давайте увійдемо та запустимо кілька команд:

    $ id -u
    1000
    $ sudo ls /
    bin boot data dev і т.д.
    $ sudo su -
    # ls / тощо
    [...]

Це дасть щось подібне в /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

Це навіть перелічить команди, які користувач виконує як root.

Джерела:

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

Пам'ятайте, що sudo сам записує всі команди sudo в syslog, тому всіх користувачів priv'd слід навчати не просто sudo отримати кореневу оболонку, а й:

sudo command p1 p2 ... pn

Проблема цього чи будь-якого підходу, який я задумав, полягає в тому, що як rootкористувач, досить важко запобігти користувачеві ухилення від конкретного типу журналу. Таким чином, все, що ви спробуєте, буде <100%.

Освіта, документація, правозастосування і перш за все довіра - це те, що необхідно.

Я колись стикався з тією ж проблемою, і мені довелося придумати швидке і брудне рішення - кожен користувач sudo матиме свій власний файл історії, коли виконає команду sudo -i

В /root/.bashrcя додав наступний рядок -

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

Таким чином, кожен користувач, котрий зможе отримати root, матиме файл історії .bash_history-username.

Інший метод -

Додайте до цього коду наступний код, /root/.bashrcі він додасть ім'я користувача, sudo-користувача та команду до файлу журналу, де колись встановлено рівень повідомлення, швидше за все / var / log / messages.

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

Ряд закладів фактично забороняє використання аудиту, оскільки це ресурсомістке і може спричинити можливість відмови в сервісних атаках.

Одне рішення - налаштувати останню оболонку Korn (ksh-93, докладні відомості див. На http://kornshell.com/ ) для реєстрації всіх команд, що виконуються як root, на віддалений сервер syslog, а потім вимагати від політики, яка, за винятком надзвичайних ситуацій У деяких випадках sysadmins увійти з особистими акаунтами та виконати розширену оболонку Korn через sudo. Експертиза журналів може виявити, коли адміністратор запускає іншу оболонку з затвердженої оболонки, щоб покрити їх доріжки, і SA може потім навчатись за необхідності.

Судо грає щось, що називається sudoreplay, коли ввімкнені сеанси реєструються і можуть бути відтворені пізніше, працює аналогічно scriptкоманді, що створює машинопис сеансу терміналу, який згодом може бути відтворений scriptreplayкомандою.

Оскільки версія 2.0.0 snoopy здатна реєструвати довільну екологічну змінну.

Однак нещодавній внесок вказував на те, що реєстрація власника tty є досить ефективною та елегантною відповіддю на питання "Хто виконав цю команду як root?".

Розкриття: Я супроводжувач снупи.

Не те, що в цьому немає нічого поганого з будь-яким з інших відповідей, але якщо ви вирішите, що sudoреєстрація через syslogнього задовільна, я можу запропонувати зморшку: зареєструйте її через мережу до віддаленого хоста аудиту.

Це вирішує проблему "тепер я зажив корінь, я можу видалити будь-який слід своєї злочинності з журналів". Тепер ви можете мати корінь у локальному вікні, але ви не можете зателефонувати до цього пакета журналу з мережі, і ви (мабуть) не маєте привілеїв root на віддаленому хості аудиту.

Я роблю це з деякими мережами, якими я керую протягом багатьох років, і це має дві інші переваги сигналу:

По-перше, в мережі є одне місце для перевірки всіх системних журналів, що дозволяє набагато простіше співвідносити інциденти, а також це єдиний приклад для розслідувань на кшталт "Коли junoскаржився, що сервер NFS heraне відповідає, чи хтось ще скаржився на одночасно те саме? Якщо так, heraшвидше за все, це буде проблемою, давайте подивимося, що вона зареєструвалась; якщо ні, junoмережеве з'єднання є більш підозрілим, давайте подивимося, що ще junoреєструвало на той момент. "

По-друге, обертання журналу syslog стає простішим: ви не зберігаєте копії журналів на локальних хостах більше декількох днів, але ви впевнені, що сервер аудиту має величезну кількість дискового простору, і зберігаєте там усі систематизовані системи протягом декількох років. Плюс, якщо, скажімо, ви хочете записати їх у засоби масової інформації WORM, наприклад, з метою судового аудиту, вам потрібно придбати лише один привід WORM.