iptables changes triggering audit messages, despite auditd not being installed
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/
Reply to: