Debian 7.10 I recently installed auditd very briefly, to test something for a StackExchange question. It was installed for less than a couple of minutes, I create a single audit rule to watch a directory, and then uninstalled it.
After it was uninstalled, I've been getting the following entries in kern.log May 2 12:58:14 trinity kernel: [5757485.373768] type=1325 audit(1462190294.794:81): table=filter family=2 entries=54 May 2 12:58:14 trinity kernel: [5757485.373846] type=1300 audit(1462190294.794:81): arch=40000003 syscall=102 success=yes exit=0 a0=e a1=bf8cb380 a2=b7754ff4 a3=2128 items=0 ppid=1736 pid=1737 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="iptables" exe="/sbin/xtables-multi" key=(null) May 2 14:34:51 trinity kernel: [5763282.057294] type=1325 audit(1462196091.475:82): table=filter family=2 entries=55 May 2 14:34:51 trinity kernel: [5763282.057370] type=1300 audit(1462196091.475:82): arch=40000003 syscall=102 success=yes exit=0 a0=e a1=bfce29f0 a2=b7736ff4 a3=2094 items=0 ppid=12057 pid=12058 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="iptables" exe="/sbin/xtables-multi" key=(null) May 2 15:31:28 trinity kernel: [5766679.552808] type=1325 audit(1462199488.973:83): table=filter family=2 entries=54 May 2 15:31:28 trinity kernel: [5766679.552884] type=1300 audit(1462199488.973:83): arch=40000003 syscall=102 success=yes exit=0 a0=e a1=bfc402f0 a2=b7718ff4 a3=2128 items=0 ppid=18365 pid=18366 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="iptables" exe="/sbin/xtables-multi" key=(null) As you can see, they're being triggered by iptables (which in turn is being triggered by fail2ban updates). I can't find why the log entries are being created (i.e. I know the trigger, but I can't work out why that trigger is now generating log entries when it wasn't doing that before I installed and removed auditd). I re-installed auditd to see if I could find any rules that had hung around, and there were none, more interestingly though, while auditd is installed, the messages *stop* (although iptables updates continue). When I remove auditd, the messages return. I've confirmed this by comparing logs from fail2ban, apt and kern.log. Before first install of auditd - fail2ban adds entries to iptables, nothing shows up in kern.log While auditd was first installed - no conclusive information because no iptables updates during that short duration After auditd was removed - fail2ban adds entries to iptables and an identically timestamped entry shows up in kern.log (as above). Several days pass and I reinstall auditd. While auditd is installed again - fail2ban adds entries to iptables, nothing shows up in kern.log After auditd is removed again - fail2ban adds entries to iptables and an identically timestamped entry shows up in kern.log Any offers about where to look? -- Tony Evans 'A learning experience is one of those things that say, "You know that thing you just did? Don't do that."' Douglas Adams. Photos: http://www.flickr.com/photos/eightbittony/ | Blog: http://perceptionistruth.com/
