Вопрос: Записывать все команды, запускаемые администраторами на производственных серверах


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

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


61
2018-01-20 04:35


Источник


Тебе нужно auditd, - Michael Hampton♦
Это краткое введение к аудиту - Deer Hunter
Может кто-нибудь, пожалуйста, опубликуйте это как ответ? Пожалуйста, укажите, как я буду строго регистрировать все команды, выполняемые пользователями. «Краткое введение в auditd» было полезно, но в нем не было ничего связанного с протоколированием фактических команд (насколько я мог бы сказать в любом случае). - Soviero
Хорошо, я начал играть с auditd, и пока я получил его для регистрации всех запущенных команд, он не включает SUDO_USER переменная (или эквивалентная информация), и я не могу найти способ ее включения. Любая помощь будет принята с благодарностью! - Soviero
И что будет компания делать с этой записью всех команд, введенных администраторами? - ewwhite


Ответы:


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

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

Как предложил Майкл Хэмптон, 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 exit, всегда -F arch = b32 -F euid = 0 -S execve

Они будут отслеживать все команды, выполняемые root (euid=0). Почему два правила? execve syscall должен отслеживаться как в 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 и т. д. 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.

Источники:


71
2018-02-04 09:16



+50 Этот ответ кажется наиболее полным, хотя я немного разочарован тем, что он оказался довольно сложным. Спасибо за ваш вклад. - grassroot
Будьте предупреждены, что эти изменения могут значительно увеличить объем журнала в /var/log/audit/audit.log. Мое количество журналов в этом файле более чем удвоилось после добавления двух строк в audit.rules - JDS


Помните, что сам sudo записывает все команды sudo в syslog, поэтому всем приватным пользователям следует обучать не просто sudo для получения корневой оболочки, а для:

sudo command p1 p2 ... pn

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

Образование, документация, правоприменение и, прежде всего, доверие - это то, что необходимо.


8
2018-01-20 06:46



Я понимаю, что ничего не будет идеально, но мы никогда не сможем заставить всех работать, как вы описываете. Это сисадмины, о которых мы говорим;) - Soviero
Неправда ... по крайней мере две очень крупные компании, с которыми я лично работал, состоящие из большого числа системных администраторов, имеют эту самую политику! Опять же, с образованием и правоприменением он работает. - mdpc
mdpc на 100% правильнее. Это именно то, для чего предназначена команда sudo. Я в магазине из десяти системных администраторов с сотнями хостов, и мы используем индивидуальные команды sudo для всего - существует определенная политика, которая запрещает становиться root через su. Это единственный разумный способ обеспечить правильную проверку работы администратора. - Jeff Albert
-1 Образование никогда этого не сделает. Мы живем в мире, где вы являетесь одним из многочисленных клиентов ваших системных администраторов. - grassroot


Я когда-то сталкивался с той же проблемой и должен был придумать быстрое и грязное решение - каждый пользователь 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


4
2018-01-31 20:03



Хороший подход, хотя и не совсем то, что было задано. Я бы хотел увидеть ревизию или подобное решение. - grassroot
Хорошо, я обновил его, чтобы полагаться на метод ловушки. - Daniel t.
И для законных пользователей это работает. Но если эта учетная запись была взломана, взломщик мог бы быстро отключить историю bash, выполнив /bin/sh, unset HISTFILE или /bin/bash --norc, - Stefan Lasiewski


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

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


3
2018-02-06 19:28





Начиная с версии 2.0.0 выслеживающий способен регистрировать произвольную переменную окружения.

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

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


3
2017-11-05 23:20



Пожалуйста, предоставьте инструкции по настройке в соответствии с требованиями OP, а не простой ссылке. Благодарю. - Andrea Lazzarotto
-1. Это просто штекер для snoopy. Вы следовали раскрытию, но вы все еще не ответили на вопрос в своем посте; вы просто связаны с вашим проектом. - Duncan X Simpson


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


3
2018-04-21 21:09





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

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

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

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

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


1
2018-02-04 09:27