Вы можете попробовать
find `pwd` -type d
Или замените pwd на абсолютный путь к вашей папке
Есть 2 варианта.
Использование фильтров 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" ~
Хотя мне удалось остановить запись тысяч журналов в день в /var/log/syslog
и /var/log/auth.log
, похоже, не было способа остановить регистрацию SSH-входов служебной учетной записи из clustercontrol в /var/log/wtmp
и /var/log/lastlog
. ] файлы.
Для этого используем logrotate(См. ниже ).
Первым шагом к пониманию того, что происходит, было включение отладочных сообщений. Проблема заключалась в том, что в моей Ubuntu 18.04 отладочные сообщения pam не регистрировались -, пока я явно не указал rsyslog , в какой файл записывать отладочные сообщения при использовании:
$ vi /etc/rsyslog.d/50-default.conf
*.debug /var/log/debug.log
$ service rsyslog restart
Это модуль 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 .
Найдите строку в /etc/pam.d/ sshd , содержащую файл common-session
, и добавьте собственный оператор pam_succeed_if.so
непосредственноперед .
Теперь выполнитепочтито же самое для файла /etc/pam.d/sudo , но здесь синтаксис нашего пользовательского правила немного отличается.
Непосредственно перед запуском наших правил pam_unix.so
из файла @include common-session
мы размещаем правило нашего модуля pam_succeed.so
.
$ 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
.
Даже глобальная установка директив 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 месяцев.