Недавно мы начали использовать auditd на одном из наших серверов Ubuntu.
В предоставленном нам примере файла audit.rules есть такое правило:
-w /var/log/syslog -p wra -k logs
Однако, когда syslog записывает в файл, auditd ничего не регистрирует. Точно так же, если я перейду в командную строку и запустил logger , файл системного журнала записывается без создания журнала аудита. Если я изменяю файл напрямую, используя редактор или добавляя к нему строку из командной строки, он регистрируется.
Конечно, мне не нужен журнал аудита каждый раз, когда пишется системный журнал, но мне интересно знать, что вызывает это, и есть ли какие-либо другие случаи, помимо системного журнала, когда это могло происходить без моего ведома.
Большое спасибо!
Дополнительная информация:
Тестовый файл audit.rules:
-D
-b 8192
-f 1
-w /var/log/syslog -p wra -k logs
Выход auditctl -l и augenrules --check:
# auditctl -l
-w /var/log/syslog -p rwa -k logs
# augenrules --check
/sbin/augenrules: Rules have changed and should be updated
Использование регистратора:
# logger "logger example"
# ausearch -k logs
----
time->Fri Mar 10 14:35:20 2017
type=CONFIG_CHANGE msg=audit(1489156520.983:4463): auid=4294967295 ses=4294967295 op="add_rule" key="logs" list=4 res=1
Использование эха и перенаправления вывода:
# echo "echo example" >> /var/log/syslog
# ausearch -k logs
----
time->Fri Mar 10 14:35:20 2017
type=CONFIG_CHANGE msg=audit(1489156520.983:4463): auid=4294967295 ses=4294967295 op="add_rule" key="logs" list=4 res=1
----
time->Fri Mar 10 14:36:52 2017
type=PROCTITLE msg=audit(1489156612.334:4465): proctitle="bash"
type=PATH msg=audit(1489156612.334:4465): item=1 name="/var/log/syslog" inode=417506 dev=08:01 mode=0100640 ouid=104 ogid=4 rdev=00:00 nametype=NORMAL
type=PATH msg=audit(1489156612.334:4465): item=0 name="/var/log/" inode=411799 dev=08:01 mode=040775 ouid=0 ogid=108 rdev=00:00 nametype=PARENT
type=CWD msg=audit(1489156612.334:4465): cwd="/etc/audit"
type=SYSCALL msg=audit(1489156612.334:4465): arch=c000003e syscall=2 success=yes exit=3 a0=a93108 a1=441 a2=1b6 a3=7ffe24385b98 items=2 ppid=28462 pid=28463 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts18 ses=4294967295 comm="bash" exe="/bin/bash" key="logs"
Хвост / var / log / syslog:
# tail -n 2 /var/log/syslog
Mar 10 14:36:40 testserver root: logger example
echo example
Я понял причину такого поведения.
В auditctl справочная страница для -p флаг гласит:
Опишите тип доступа к разрешениям, который запускается при просмотре файловой системы. r = чтение, w = запись, x = выполнение, a = изменение атрибута. Эти разрешения не являются стандартными разрешениями для файлов, а скорее являются типом системного вызова, который может делать такие вещи. Системные вызовы чтения и записи не включены в этот набор, поскольку они могут привести к переполнению журналов. Но для чтения или записи используются флаги открытия, чтобы узнать, какое разрешение было запрошено.
В то время я не понимал, что это означало, но после пары часов копания в списке рассылки linux-audit я понял, что это означает, что если вы смотрите файл для записи, он не регистрируется, когда есть системный вызов для записи в файл. Он просто регистрирует доступ к файлу с разрешениями на запись, проверяя наличие open системные вызовы с O_RDWR или O_WRONLY флаги.
Итак, когда я использую logger на самом деле я прошу демон Syslog записать в файл за меня. У демона системного журнала этот файл всегда открыт для записи, поэтому логично, что ничего не регистрируется.
Если я перезапущу демон Syslog, в моих журналах аудита будет примерно следующее:
# ausearch -i -k logs
----
type=PROCTITLE msg=audit(10-03-2017 16:16:59.128:4613) : proctitle=/usr/sbin/rsyslogd -n
type=PATH msg=audit(10-03-2017 16:16:59.128:4613) : item=1 name=/var/log/syslog inode=417506 dev=08:01 mode=file,640 ouid=syslog ogid=adm rdev=00:00 nametype=NORMAL
type=PATH msg=audit(10-03-2017 16:16:59.128:4613) : item=0 name=/var/log/ inode=411799 dev=08:01 mode=dir,775 ouid=root ogid=syslog rdev=00:00 nametype=PARENT
type=CWD msg=audit(10-03-2017 16:16:59.128:4613) : cwd=/
type=SYSCALL msg=audit(10-03-2017 16:16:59.128:4613) : arch=x86_64 syscall=open success=yes exit=6 a0=0x7f5848003fb0 a1=O_WRONLY|O_CREAT|O_NOCTTY|O_APPEND|O_CLOEXEC a2=0640 a3=0x7f5848000088 items=2 ppid=1 pid=10638 auid=unset uid=syslog gid=syslog euid=syslog suid=syslog fsuid=syslog egid=syslog sgid=syslog fsgid=syslog tty=(none) ses=unset comm=rs:main Q:Reg exe=/usr/sbin/rsyslogd key=logs
Вы можете начать с проверки, активно ли правило в настоящее время, найдя его в выходных данных sudo auditctl -l.
Если auditd был настроен на неизменяемость набора правил (например, ваш /etc/audit/audit.rules содержит -e 2), тогда только перезагрузка сделает новые правила активными.
Если правило видно, вы получите что-нибудь если ты бежишь sudo ausearch -k logs? Кроме того, что вы получите, если запустите sudo augenrules --check?
Как вы говорите, ведение журнала каждой записи в / var / log / syslog (или / var / log / messages) может быть немного шумным, поэтому вы можете рассмотреть возможность исключения root и / или любого пользователя, который используется для непривилегированных компонентов syslog. Как только это сработает.