Журнал всех команд, запущенных администраторами на производственных серверах

В соответствии с политикой компании администраторы могут войти на сервер через личное имя пользователя, а затем запустить, sudo -iчтобы стать пользователем root. После запуска sudo -isudo создаст переменную окружения с именем SUDO_USER, которая содержит исходное имя пользователя.

Есть ли способ войти ВСЕ команды в системный журнал с чем-то похожим на следующий синтаксис:

${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 установить random-pkg).

Я уже пробовал snoopy, но он не включал SUDO_USERпеременную.

Обновление : еще 2 вещи, которые появились в комментариях и в последующих вопросах:

• Использование auditdэтого способа значительно увеличит объем вашего журнала, особенно если система интенсивно используется через командную строку. Настройте политику хранения журналов.
• Auditdжурналы на хосте, на котором они созданы, так же безопасны, как и другие файлы в том же ящике. Перешлите ваши журналы на удаленный сервер сбора журналов, такой как ELK или Graylog, чтобы сохранить целостность ваших журналов. Плюс, добавляя к пункту выше, это позволяет более агрессивно удалять старые журналы.

Как было предложено Майклом Хэмптоном, auditdэто правильный инструмент для работы здесь.

Я проверил это на установке Ubuntu 12.10, поэтому ваш пробег может отличаться на других системах.

• Установить auditd:

  apt-get install auditd

• Добавьте эти 2 строки к /etc/audit/audit.rules:

  -a выход, всегда -F arch = b64 -F euid = 0 -S execve
  -a выход, всегда -F arch = 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, которые имеют отношение к login ( /etc/pam.d/{login,kdm,sshd}), но не в файлах, которые имеют отношение к suили sudo. Это позволит auditdправильно узнать вызывающего пользователя uidпри звонке sudoили su.

• Перезагрузите вашу систему сейчас.

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

    $ id -u
    1000
    $ sudo ls /
    bin загрузочные данные dev и т. д. home initrd.img initrd.img.old lib lib32 lib64 потерян + найден носитель mnt opt ​​proc root run sbin scratch selinux srv sys tmp usr var vmlinuz vmlinuz.old
    $ 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

Это даже перечислит команды, которые пользователь выполнил как root.

Источники:

• 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 в системном журнале, поэтому всем привилегированным пользователям следует научиться не просто использовать 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-user и команду в файл журнала, где бы ни был установлен уровень уведомления, скорее всего, / 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

Ряд предприятий фактически запрещают использование audd, поскольку он требует значительных ресурсов и может привести к возможности атак типа «отказ в обслуживании».

Одним из решений является настройка последней оболочки Korn (ksh-93, для получения подробной информации см. Http://kornshell.com/ ) для регистрации всех команд, выполненных от имени пользователя root, на удаленном сервере системного журнала, а затем для этого требуется политика, за исключением случаев крайней необходимости. В таких ситуациях системные администраторы входят в систему с личными учетными записями и запускают улучшенную оболочку Korn через sudo. Изучение журналов может обнаружить, когда администратор запускает другую оболочку из утвержденной оболочки, чтобы покрыть свои следы, и затем SA может быть обучен по мере необходимости.

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

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

Это обходит проблему «теперь, когда я стал пользователем root, я могу удалить любой след моего злоумышленника из журналов». Теперь вы можете быть пользователем root на локальном компьютере, но вы не можете вызвать этот пакет журнала обратно из сети, и у вас (предположительно) нет привилегий root на удаленном узле аудита.

Я делал это с некоторыми сетями, которыми управляю годами, и у него есть два других преимущества сигнала:

Во-первых, в сети есть одно место для проверки всех системных журналов, что позволяет значительно упростить корреляцию инцидентов, а также универсальный магазин для расследований типа «Когда junoжаловался, что сервер NFS heraне отвечает, был ли кто-то еще жаловался на то же самое в то же время? Если так, то hera, вероятно, проблема, давайте посмотрим, что она зарегистрировала; если нет, то junoсетевое подключение более подозрительно, давайте посмотрим, что еще junoрегистрировалось в то время. "

Во-вторых, ротация журналов системного журнала становится проще: вы не храните копии журналов на локальных хостах более нескольких дней, но вы проверяете, что на сервере аудита есть огромное количество дискового пространства, и сохраняете там все системные журналы в течение нескольких лет. Кроме того, если, скажем, вы хотите записать их на носитель WORM, например, для целей судебной экспертизы, вам нужно только купить один диск WORM.

Начиная с версии 2.0.0, Snoopy может регистрировать произвольные переменные среды.

Тем не менее, недавний вклад указал, что регистрация владельца tty является довольно эффективным и элегантным ответом на вопрос «Кто выполнил эту команду от имени root?».

Раскрытие информации: я любопытный сопровождающий.