Excluding audit for BIND daemon

Sat Sep 23 14:08:40 UTC 2017

Continued...from previous mail of mine..

While I am reading and exploring much on auditd & on how I can have a
proper central system where logs are stored and daily reports get
generated, you might want to look at my config file on server and
suggest/recommend if anything - would appreciate if any pointers.

I am using default config which came with Ubuntu 16.04 and only change was*
"-F auid!=4294967295"* on line where root_action is defined .

Thanks!

Best Regards,
Rituraj B

On Sat, Sep 23, 2017 at 7:30 PM, Rituraj Buddhisagar <rituraj at vayana.com>
wrote:

> Hi Steve,
>
> Thanks for the response.
>
> Suppressing the events with -F auid!=4294967295 worked.
>
> I am seeing the events like "vi" "chmod" etc are getting audited by the
> system - even as a root account.
>
> I am yet to understand fully though on various rule sets and also on
> components like audisp / audisp-remote. So reading more ..
>
>
> Best Regards,
> Rituraj B
>
>
> On Fri, Sep 22, 2017 at 10:17 PM, Steve Grubb <sgrubb at redhat.com> wrote:
>
>> Hello,
>>
>> On Friday, September 22, 2017 1:09:19 AM EDT Rituraj Buddhisagar wrote:
>> > I have a DNS server for which the auditd was generating lot of system
>> calls
>> > and flooding the logs.
>> > Due to this  the server was under heavy memory usage as audisp-remote
>> was
>> > hogging the memory.  The log output for audisp-remote showed that the
>> > syscall was 49. Then I got to know from ausyscall command that the call
>> > number 49 corresponds to bind. Hence I have *excluded* the call to
>> "bind".
>> >
>> > I have put in below line in the /etc/audit/audit.rules
>> >
>> > *-a exclude,always -S 49*
>> >
>> > I have put the above line before section 10.2.2 which says "Feel free to
>> > add below this line" (please note I am running Ubuntu 14.04 but I
>> suppose
>> > auditd implementation is same across board) .
>>
>> Also know that the rules are looked at from top to bottom with the first
>> match
>> winning. So, you would want this rule above whatever is causing events.
>>
>>
>> > After the exclusion - I no more see the syscall=49 line in
>> > /var/log/audit/audit.rules. So thats a success of sorts!
>> >
>> > *Probem/Issue/Query now*: After the exclusion, I do see audit events for
>> > cron , sudo etc. But I do not see a call for "vi" file open mode etc.
>>
>> I'd need to see the rules to figure out what's wrong, but I have some
>> hints
>> below...
>>
>> > *Background:*
>> >
>> > log output earlier which was flooding the logs and giving message "
>> *dns1
>> > audisp-remote: message repeated 6613 times: [ queue is full - dropping
>> > event"*
>> >
>> > *log:*
>> > *type=SYSCALL msg=audit(1506025977.586:46629194): arch=c000003e
>> syscall=49
>> > success=yes exit=0 a0=3 a1=7ffe540ecf20 a2=c a3=0 items=0 ppid=22337
>> > pid=22338 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
>> sgid=0
>> > fsgid=0 tty=(none) ses=4294967295 comm="audisp-remote"
>> > exe="/sbin/audisp-remote" key="root_action"*
>>
>> The main question is what is the root_action rule(s)? Normally we add a
>> auid!=4294967295 to prevent daemons from causing events. Typically when
>> it's
>> desired to get root events, its means that you want to target _people_
>> running
>> as root rather than normal system activity.
>>
>>
>> > root at dns1:/tmp# ausyscall 49
>> > *bind*
>> >
>> > I do see audit events for cron , sudo etc. But I do not see a call for
>> "vi"
>> > file open mode etc.
>> >
>> > Observation: I open file /etc/audit/audit.rules in vi editor and then
>> close
>> > it. Audit log does not show syscall=2
>>
>> If you were wanting to record writes to that, you would use a rule like
>> this:
>>
>> -w /etc/audit/ -p wa
>>
>>
>> > Earlier I used to see below output in logs, but I am not sure that was
>> for
>> > which file opened in vi editor.
>> >
>> > *type=SYSCALL msg=audit(1506025995.825:46633170): arch=c000003e
>> syscall=2
>> > success=yes exit=3 a0=5598f609a210 a1=200c1 a2=81a0 a3=0 items=2
>> ppid=21957
>> > pid=22355 auid=1006 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
>> fsgid=0
>> > tty=pts0 ses=361 comm="vi" exe="/usr/bin/vim.basic" key="root_action"*
>>
>> Typically, its expected to look at events through ausearch. It groups the
>> records into events. You can also use aureport to see summary information.
>>
>> > I did read a bit on auditd from below links. *Please let me know if I am
>> > missing something or are the calls getting audited in an expected way.*
>>
>> >
>> > I went through below links; *would appreciate if someone can help with
>> any
>> > references which are more lucid with example*s:
>> >
>> > https://linux-audit.com/configuring-and-auditing-linux-
>> systems-with-audit-da
>> > emon/
>>
>> I was not aware of that site. But some of the information appears to be
>> dated.
>> For example, telling people to use pam_tally2 when they should be using
>> pam_faillock.
>>
>> > https://access.redhat.com/documentation/en-US/Red_Hat_Enterp
>> rise_Linux/6/ht
>> > ml/Security_Guide/chap-system_auditing.html
>> >
>> > Furthermore, I would like to read much on audisp-remote to send all
>> these
>> > logs to a central server. I do not find any documentation on that. I see
>> > discussion on net where people are using rsyslog instead for that.
>> Please
>> > help with references/links if any.
>>
>> Admittedly there is not much written. It is on my list of topics to blog
>> about. But I haven't had time for blogging lately.
>>
>> -Steve
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20170923/26139144/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: audit-rules.doc
Type: application/msword
Size: 13824 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20170923/26139144/attachment.doc>