Excluding audit for BIND daemon

[Steve Grubb]

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_Enterprise_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