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

Это политика компании для администраторов, чтобы войти на серверы через личное имя пользователя, а затем запустить sudo -i стать корнем. После запуска sudo -i, sudo создаст переменную среды с именем 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 переменная.

Источник

7 ответов

Решение

Обновление: еще 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, которые имеют отношение к входу в систему (/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.

Источники:

Источник

Помните, что сама 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

Источник

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

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

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

Источник

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

Источник

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

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

Источник

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

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

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

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

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

Источник
Другие вопросы по тегам