[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

iptables changes generating audit entries in kern.log despite auditd not being installed



Debian 7.10

I recently installed auditd to test something for a StackExchange
query.  I removed it after around 2 minutes (after creating a single
filesystem monitoring rule).

Subsequently, something is logging to kern.log every time iptables is
executed (which in turn, is being triggered by fail2ban updates).

These are the entries in kern.log (or a sample of them).

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)

Subsequent testing showed that if I reinstalled auditd, the messages
stop (without taking any other action, there are no defined rules).
So the sequence of events is,

1. prior to the installation of auditd, no entries in kern.log
2. installed and removed auditd in the space of 2 minutes
3. iptables changes now generate the above log entries in kern.log
4. reinstalled auditd, and the messages stop, despite fail2ban still
making iptables updates during this period
5. remove auditd and the messages return immediately

Anyone have any suggestions on 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: