Audit on changes to the running iptables configuration

The following auditctl rule should suffice:

[root@vh-app2 audit]# auditctl -a exit,always -F arch=b64 -F a2=64 -S setsockopt -k iptablesChange

Testing the change:

[root@vh-app2 audit]# iptables -A INPUT -j ACCEPT
[root@vh-app2 audit]# ausearch -k iptablesChange
----
time->Mon Jun  1 15:46:45 2015
type=CONFIG_CHANGE msg=audit(1433188005.842:122): auid=90328 ses=3 op="add rule" key="iptablesChange" list=4 res=1
----
time->Mon Jun  1 15:47:22 2015
type=SYSCALL msg=audit(1433188042.907:123): arch=c000003e syscall=54 success=yes exit=0 a0=3 a1=0 a2=40 a3=7dff50 items=0 ppid=55654 pid=65141 auid=90328 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=3 comm="iptables" exe="/sbin/iptables-multi-1.4.7" key="iptablesChange"
type=NETFILTER_CFG msg=audit(1433188042.907:123): table=filter family=2 entries=6
[root@vh-app2 audit]# ps -p 55654
  PID TTY          TIME CMD
55654 pts/0    00:00:00 bash
[root@vh-app2 audit]# tty
/dev/pts/0
[root@vh-app2 audit]# cat /proc/$$/loginuid
90328
[root@vh-app2 audit]#

As you can see from the above output, after auditing for calls to setsockopt when optname (the a2 field) is IPT_SO_SET_REPLACE (which is 64 decimal per the Linux kernel source code) it was able to log changes to the running iptables configuration.

I was then able to catch the relevant audit information such as the the user's loginuid (since they would likely have sudo'd to root prior to updating the firewall) as well as the PID of the calling program.