Остановить чрезмерное ведение журнала входов SUDO и SSH в системный журнал и WTMP для определенной учетной записи пользователя

Вы можете попробовать

find `pwd` -type d

Или замените pwd на абсолютный путь к вашей папке

1
03.03.2021, 04:58
1 ответ

Есть 2 варианта.

TL;DR

1. Фильтры системного журнала

Использование фильтров rsyslogявляется самым быстрым решением, но не таким всеобъемлющим, как PAM .

В верхней части файла конфигурации по умолчанию rsyslog добавьте ключевые слова, по которым вы хотите фильтровать, и команду фильтра. В этом случае команда фильтра удаляет ('~').

$ vi /etc/rsyslog.d/50-default.conf
:msg, contains, "clustercontrol" ~
:msg, contains, "pam_unix(sudo:session): session closed for user root" ~
:msg, contains, "Removed session" ~

2. Управление файлами журналов

Хотя мне удалось остановить запись тысяч журналов в день в /var/log/syslogи /var/log/auth.log, похоже, не было способа остановить регистрацию SSH-входов служебной учетной записи из clustercontrol в /var/log/wtmpи /var/log/lastlog. ] файлы.

Для этого используем logrotate(См. ниже ).

Использование PAM

Отладка PAM

Первым шагом к пониманию того, что происходит, было включение отладочных сообщений. Проблема заключалась в том, что в моей Ubuntu 18.04 отладочные сообщения pam не регистрировались -, пока я явно не указал rsyslog , в какой файл записывать отладочные сообщения при использовании:

$ vi /etc/rsyslog.d/50-default.conf
*.debug           /var/log/debug.log

$ service rsyslog restart

pam _успех _if.so

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

Понять, кто ведет регистрацию

Внутри /var/log/auth.logвы увидите сообщения журнала, которые мы хотим остановить для этой учетной записи пользователя:

Mar 17 13:05:27 dev1 sshd[18833]: pam_unix(sshd:session): session opened for user clustercontrol by (uid=0)

Mar 17 13:04:25 dev1 sudo: pam_unix(sudo:session): session opened for user root by clustercontrol(uid=0)

Из приведенных выше журналов мы можем сказать, что pam _unix.so — это модуль аутентификации pam, который ведет журнал. Он вызывается двумя отдельными службами sshd и sudo .

Маркер типа pam сообщает pam, какой тип аутентификации следует использовать для этого модуля. В этом случаесессия— это то, что нужно сделать до и/или после аутентификации пользователя.

Ответственная конфигурация PAM

Итак, давайте найдем модуль pam pam_unix.so, отвечающий за эти журналы в конфигурации нашей системы.

$ cd /etc/pam.d

$ grep 'pam_unix.so' * -in
common-account:17:account       [success=1 new_authtok_reqd=done default=ignore]        pam_unix.so 
common-auth:17:auth     [success=1 default=ignore]      pam_unix.so nullok_secure
common-password:25:password     [success=1 default=ignore]      pam_unix.so obscure sha512
common-session:29:session       required        pam_unix.so 
common-session-noninteractive:30:session        required        pam_unix.so 
runuser:5:session               required        pam_unix.so

Из приведенного выше видно, что модуль pam_unix.soдля «:сеанса» находится в файле common-sessionв строке#29 .

ВАЖНЫЙ
  1. Найдите строку в /etc/pam.d/ sshd , содержащую файл common-session, и добавьте собственный оператор pam_succeed_if.soнепосредственноперед .

  2. Теперь выполнитепочтито же самое для файла /etc/pam.d/sudo , но здесь синтаксис нашего пользовательского правила немного отличается.

Пользовательские правила PAM

Последовательность важна

Непосредственно перед запуском наших правил pam_unix.soиз файла @include common-sessionмы размещаем правило нашего модуля pam_succeed.so.

правило sshd
$ grep -in include /etc/pam.d/sshd
5:@include common-auth
15:@include common-account
29:@include common-session
32:# This includes a dynamically generated part from /run/motd.dynamic
56:@include common-password

Строка 29 в нашем случае.

$ vi /etc/pam.d/sshd +29
session [success=done default=ignore] pam_succeed_if.so quiet service in sshd user = clustercontrol
# Standard Un*x session setup and teardown.
@include common-session

Было бы проще, если бы мы читали правила от конца к началу:

Мы проверяем, аутентифицирован ли пользователь с именем clustercontrol(user = clustercontrol)с помощью sshd (service in sshd), тогда это правило соответствует, и запускаем директиву (quiet), которая делает ведение журнала тихим .

Часть [success=done означает, что если вы получаете совпадение с этим правилом, мы done, поэтому пропустите обработку следующих правил или пропустите следующее правило в стеке pam.

Это эффективно останавливает ведение журнала sshd для этого пользователя.

правило судо

Для этого я добавил строку#6 в /etc/pam.d/sudo:

$ vi /etc/pam.d/sudo
:set number 

  1 #%PAM-1.0
  2 
  3 session    required   pam_env.so readenv=1 user_readenv=0
  4 session    required   pam_env.so readenv=1 envfile=/etc/default/locale user_readenv=0
  5 
  6 session [success=done default=ignore] pam_succeed_if.so quiet uid = 0 ruser = clustercontrol
  7 @include common-auth
  8 @include common-account
  9 @include common-session-noninteractive

session [success=done default=ignore] pam_succeed_if.so quiet uid = 0 ruser = clustercontrol

Здесь у нас немного другой синтаксис.Sudo обычно запускает команды от имени пользователяroot(, если в специальных директивах не указано иное ). В unix-подобных системах этоuser 0.

Итак, наше пользовательское правило гласит, что если команда sudo запускается в контексте пользователя с uid 0 удаленным пользователем(ruser ), в нашем случае это clustercontrol , затем тихо с ведением журнала, и мы сделали , поэтому пропустите любые дальнейшие правила для этого пользователя типа сеанса аутентификации.

Примечание
Не забудьте закомментировать строку *.debugв /etc/rsyslog.d/50 -default.conf и перезапустить службу с помощью $ service rsyslog restart.

Логротация

Ластлог + wtmp

Даже глобальная установка директив noupdateили nowtmpдля pam_lastlog.soне повлияла на мою систему, поэтому я просто регулярно сжимал и ротировал эти журналы, используя приведенную ниже конфигурацию logrotate.

$ vi /etc/logrotate.conf
# no packages own wtmp, or btmp -- we'll rotate them here
/var/log/wtmp {
    missingok
    monthly
    create 0664 root utmp
    rotate 12
    size 200M
    compress
}

/var/log/btmp {
    missingok
    monthly
    create 0660 root utmp
    rotate 12
    size 200M
    compress
}

Журналы будут меняться ежемесячно или каждые 200 МБ, в зависимости от того, что наступит раньше. Журналы будут сжаты и сохранены в течение максимум 12 месяцев.

2
18.03.2021, 22:27

Теги

Похожие вопросы