Политика компании заключается в том, что администраторы могут входить на серверы с помощью личного имени пользователя, а затем запускать sudo -i стать root. При беге 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 переменная.
Обновить: Еще 2 вещи, которые всплывали в комментариях и в дополнительных вопросах:
auditd это значительно увеличит объем вашего журнала, особенно если система активно используется через командную строку. Измените политику хранения журналов.Auditd журналы на хосте, где они созданы, так же безопасны, как и другие файлы в том же ящике. Пересылайте свои журналы на удаленный сервер сбора журналов, например ELK или Graylog, чтобы сохранить целостность журналов. Кроме того, в дополнение к вышесказанному, он позволяет более агрессивно удалять старые журналы.Как было предложено Майклом Хэмптоном, auditd это правильный инструмент для работы здесь.
Я тестировал это на установке Ubuntu 12.10, поэтому ваш опыт может отличаться в других системах.
Установить auditd:
apt-get install auditd
Добавьте эти 2 строки в /etc/audit/audit.rules:
-a exit,always -F arch=b64 -F euid=0 -S execve -a exit,always -F arch=b32 -F euid=0 -S execve
Они будут отслеживать все команды, выполняемые root (euid=0). Почему два правила? В execve Системный вызов должен отслеживаться как в 32-, так и в 64-битном коде.
Избавиться auid=4294967295 сообщения в логах, добавить audit=1 в командную строку ядра (путем редактирования /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 etc home initrd.img initrd.img.old lib lib32 lib64 lost+found media 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 в системном журнале, поэтому все пользователи 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-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
Ряд предприятий фактически запрещают использование auditd, поскольку он требует значительных ресурсов и может привести к возможности атак типа «отказ в обслуживании».
Одно из решений - настроить последнюю версию оболочки Korn (ksh-93, см. http://kornshell.com/ для подробностей), чтобы регистрировать все команды, выполняемые от имени пользователя root на удаленном сервере системного журнала, а затем требовать политикой, чтобы системные администраторы, за исключением чрезвычайных ситуаций, входили в систему с личными учетными записями и выполняли расширенную оболочку Korn через sudo. Изучение журналов может определить, когда администратор запускает другую оболочку из утвержденной оболочки, чтобы замести следы, а затем SA может быть обучен по мере необходимости.
У Судо есть что-то под названием Sudoreplay когда включенные сеансы регистрируются и могут быть воспроизведены позже, работает аналогично script команда, которая делает машинописный текст сеанса терминала, который позже может быть воспроизведен с помощью scriptreplay команда.
Не то чтобы с другими ответами что-то не так, но если вы решите, что sudoвходит через syslog является удовлетворительным, могу я предложить морщину: зарегистрировать его через сеть на удаленном хосте аудита.
Это решает проблему «теперь я стал пользователем root, я могу удалить из журналов все следы моих злоупотреблений». Теперь вы можете быть пользователем root на локальном компьютере, но вы не можете вызвать этот пакет журнала обратно из сети, и у вас (предположительно) нет привилегий root на удаленном хосте аудита.
Я делал это с некоторыми из сетей, которыми управляю в течение многих лет, и у этого есть два других преимущества сигнала:
Во-первых, в сети есть одно место, где можно проверить все системные журналы, что значительно упрощает сопоставление инцидентов, а также универсальный магазин для расследований, таких как «Когда juno жаловался, что сервер NFS hera не отвечал, жаловался ли кто-нибудь еще на то же самое в то же время? Если так, hera скорее всего проблема, посмотрим, что она логинала; если не, junoподключение к сети более подозрительно, давайте посмотрим, что еще juno зарегистрирован в то время. ".
Во-вторых, ротация журналов системного журнала становится проще: вы не храните копии журналов на локальных хостах более нескольких дней, но вы должны убедиться, что на сервере аудита есть огромные объемы дискового пространства, и хранить все системные журналы там в течение нескольких лет. Кроме того, если, скажем, вы хотите записать их на носитель WORM, например, для целей судебного аудита, вам нужно купить только один диск WORM.
Начиная с версии 2.0.0 любопытный может регистрировать произвольную переменную окружения.
Однако в недавней публикации указано, что владелец логирования tty является довольно эффективным и элегантным ответом на вопрос «Кто выполнил эту команду как root?».
Раскрытие информации: я любопытный сопровождающий.