Мы настроили auditd для входа всего доступа к определенным критическим файлам. Система выполняет Сервер WebLogic, и мы хотим знать, пытается ли кто-либо ввести по абсолютному адресу вокруг чувствительных системных файлов, таких как доменный конфигурационный файл, соль шифрования, и так далее. В некоторых случаях в некоторых системах в прошлом это работало как ожидалось, но недавно это не имеет, и я в конце своего остроумия, пытающемся выяснять почему. Таким образом, я иду вразрез со своим характером и ищу внешнюю помощь с этой проблемой.
Соответствующие точки данных и возможный ведут, я занимался расследованиями:
# auditctl -l LIST_RULES: exit,always dir=/etc/audit (0xa) perm=wa key=auditsys LIST_RULES: exit,always dir=/var/log/audit (0xe) perm=wa key=auditsys
Несмотря на полный файл правил, все еще существующий.
Когда я пытаюсь перезапустить контрольного демона (сервис auditd перезапуск), я получаю следующее сообщение об ошибке:
Error sending add rule data request (No such file or directory)
There was an error in line 30 of /etc/audit/audit.rules
который оказывается, потому что один из файлов, которые мы сказали ему наблюдать, еще не существует. Я разрешаю это путем создания файла вручную и повторяюсь для каждой последующей ошибки. Мне поэтому кажется, что нельзя сделать, чтобы контрольный демон наблюдал путь заблаговременно и создание начальной буквы отчета данного файла.
Кто-либо может предложить обходное или альтернативное решение этой проблеме?
Передано из списка рассылки аудита ...
> On Mon, 2015-05-11 at 15:52 -0400, Steve Grubb wrote:
> > On Monday, May 11, 2015 11:50:19 AM Bill Jackson III wrote:
> > > Any pointers for troubleshooting auditd missing events for file reads,
> > > edits, etc. ( -w _path_ -p raw) on OEL5/RHEL 5/CentOS 5?
> > >
> > > http://security.stackexchange.com/q/89009/56827
> >
> > The -w notation is the same as
> >
> > -a always,exit -F path=XXX -F perms=rwa
> >
> > What this does is audit the following functions defined in the syscall
> > classifiers
> > :
> > http://lxr.free-electrons.com/source/include/asm-generic/audit_read.h
> > http://lxr.free-electrons.com/source/include/asm-generic/audit_write.h
> > http://lxr.free-electrons.com/source/include/asm-generic/audit_change_attr.h
> >
> > You are not going to get a hit for each and every read system call because
> > read is not audited.
>
> Bill,
>
> Is your question
>
> "Can one apply a file watch using auditd if the file does not exist?"
>
> then I believe the answer is no.
There is a patch set coming to be able to address this case if the
directory exists. Down the road, I'm hoping to be able to accomodate
non-existant directories too.
> Options would be
> - as part of your application deployment standard operating procedures
> (SOPs) add appropriate watches to audit.rules and restart the auditd
> service
> - keep all you sensitive files in one directory location, set a
> directory watch on this directory tree and then as part of your
> application deployment SOPs, place the real files in the sensitive file
> area and then link to them from the application area. (I've just tried
> this on a fc22 system and it works)
>
> Regards
- RGB
--
Richard Guy Briggs <rbriggs@redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
Здесь две мысли:
1) Рассмотрите возможность использования -i в вашем файле правил.
«Игнорировать ошибки при чтении правил из файла. Это приводит к тому, что auditctl всегда возвращает успех. код выхода ".
Это продолжает анализировать ошибки и подбирает другие правила. В противном случае у вас останутся только правила до ошибки. Очевидно, здесь есть и обратная сторона, но иногда лучше иметь правильные правила, несмотря ни на что.
2) Простой способ обращения к каталогам / файлам, которых нет при запуске, - это перезапустить / перезагрузить auditd, как только система достигнет его работоспособности. состояние.