I'm aware of how to audit for changes to the /etc/sysconfig/iptables
file in CentOS/RHEL 6 and earlier, but how do I audit for changes made only to the running configuration?
1 Answer
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.
-
It seems that
iptables-restore
cannot be caught by this rule. Any idea?– youfuOct 19, 2020 at 6:14 -
@youfu not sure, you might try to log all
setsockopt
temporarily while you do it so you know what it's setting it's arguments at. There also may be documentation somewhere on what the possible arguments are. I also don't know how the introduction of BPF affects this advice. (this answer is like five years old). Mar 4, 2021 at 19:26 -
1Recent distros ship nftables-based iptables, so apparently IPT_SO_* are not in use.– youfuMar 5, 2021 at 1:25