Description of problem: iptables does not remember changes after ssh exit/logout/login Version-Release number of selected component (if applicable): iptables-1.3.7-2 How reproducible: Always Steps to Reproduce: 1. from a remote machine, use ssh to log in as non-root user 2. use su - to get root aaccess 3. add a new rule.... i.e. iptables -I ... 4. service iptables save 5. exit 6. logout 7. connect again with ssh, get root access 8. iptables -L to list rules Actual results: the rule added in step 3 above is gone Expected results: the rule in step 3 should still be there. Additional info: after "service iptables save", using "service ip6tables save" solves the problem. The save features should not interfere with each other... Ref thread on fedora-list: https://www.redhat.com/archives/fedora-list/2007-August/msg03399.html
There seems to be something really odd. iptables is independant to ip6tables. Please attach a log files for: sh -x /etc/init.d/iptables save >& log1 sh -x /etc/init.d/ip6tables save >& log2
"service iptables save" and "service ip6tables save" are only saving the current firewall rules (iptables for ipv4 and ip6tables for ipv6) without changing the running firewall. 1) Are you rebooting the machine after adding the rule? 2) Do you have log entries in /var/log/messages? 3) Are you using lokkit or system-config-securitylevel after adding your rules?
(In reply to comment #2) > 1) Are you rebooting the machine after adding the rule? No, I seldom reboot the machine... typically only after a new kernel update via "yum update" > 2) Do you have log entries in /var/log/messages? Here is some interesting stuff.... I don't kow what this is trying to tll me though... but interestingly, iptables is mentionedright around the time of a dhcp renewal. > 3) Are you using lokkit or system-config-securitylevel after adding your rules? No.... the rules I add are for allowing the use of webwin/users from my internal network instead of only the localhost) and similar for ejabberedd ports..I'm trying to figure out how to get ejabberd working.... and running into these firewal issues along the way. selinus is set in permissive mode /etc/sysconfig/iptables-config have these two options set to "no": IPTABLES_SAVE_ON_STOP="no" IPTABLES_SAVE_ON_RESTART="no" That's default behavior... I've not made any changes to that.... Does the firewall stop/restart during a dhcp renewal? Since I explicitly use "service iptables save", would those settings make any difference? Since creating this bug report, the iptables have changed again.. so issuing the "service ip6tables save" appears to have been a coincidence... I'm going to need to do some more sleuthing to figure out exactly when my rules get dropped.... some people in the fedora-list thread are suggesting it is DHCP related.... I'll get the log files you asked for ..... Thanks
Ooops... I forgot to include the messages.... :-( Aug 19 05:30:08 localhost dhclient: DHCPREQUEST on eth0 to 10.10.10.1 port 67 Aug 19 05:30:08 localhost dhclient: DHCPACK from 10.10.10.1 Aug 19 05:30:08 localhost kernel: audit(1187526608.309:3150): avc: denied { write } for pid=25464 comm="touch" name="firestarter" dev=dm-0 ino=70615137 scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:var_lock_t:s0 tclass=file Aug 19 05:30:08 localhost kernel: audit(1187526608.633:3151): avc: denied { execute } for pid=25479 comm="sh" name="iptables" dev=dm-0 ino=2457694 scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file Aug 19 05:30:08 localhost kernel: audit(1187526608.634:3152): avc: denied { execute_no_trans } for pid=25479 comm="sh" name="iptables" dev=dm-0 ino=2457694 scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file Aug 19 05:30:08 localhost kernel: audit(1187526608.634:3153): avc: denied { read } for pid=25479 comm="sh" name="iptables" dev=dm-0 ino=2457694 scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file Aug 19 05:30:08 localhost kernel: audit(1187526608.639:3154): avc: denied { create } for pid=25479 comm="iptables" scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:system_r:dhcpc_t:s0 tclass=rawip_socket Aug 19 05:30:08 localhost kernel: audit(1187526608.640:3155): avc: denied { getopt } for pid=25479 comm="iptables" lport=255 scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:system_r:dhcpc_t:s0 tclass=rawip_socket Aug 19 05:30:08 localhost kernel: audit(1187526608.651:3156): avc: denied { setopt } for pid=25482 comm="iptables" lport=255 scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:system_r:dhcpc_t:s0 tclass=rawip_socket Aug 19 05:30:08 localhost kernel: audit(1187526608.850:3157): avc: denied { search } for pid=25449 comm="sh" scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:sysctl_net_t:s0 tclass=dir Aug 19 05:30:08 localhost kernel: audit(1187526608.850:3158): avc: denied { write } for pid=25449 comm="sh" scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:sysctl_net_t:s0 tclass=file Aug 19 05:30:08 localhost kernel: audit(1187526608.858:3159): avc: denied { read } for pid=25449 comm="sh" scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:sysctl_net_t:s0 tclass=file Aug 19 05:30:10 localhost dhclient: bound to 10.10.10.250 -- renewal in 36051 seconds.
Created attachment 164591 [details] output from sh -x /etc/init.d/iptables save >& log1 output from sh -x /etc/init.d/iptables save >& log1
Created attachment 164592 [details] output from sh -x /etc/init.d/ip6tables save >& log2 output from sh -x /etc/init.d/ip6tables save >& log2
According to your messages (comment #4) you are using firestarter. It seems that firestarter is modyfying your firewall by using iptables calls. Can you please check this?
Yes, I noticed that too... I do not know why firestarter is changing any rules. In fact, I'm not sure why I need/want firestarter in the first place. It looks as though DHCP is calling firestarter.... I base that on finding this little gem: a file called: /etc/dhclient-exit-hooks single line contents: sh /etc/firestarter/firestarter.sh start Without following the code, I would hazard a guess this causes firestarter to restart after each DHCP renewal... When "service iptables save" is used, firestarter doesn't know, and apparently firestarter is keeping track of it's own set of rules. I'm beginning to think firestarter is the real culprit here... What do you think of this approach: - mv /etc/dhclient-exit-hooks /etc/dhclient-exit-hooks-RenamedToRemove and see if the problem persists If the problem disappears... I'll kick firestarter to the curb, and this incident is "notabug"
Yes, please check if it helps.
I renamed the /etc/dhclient-exit-hooks file so it would not be used when the DHCP renewal process completed... and sure enough, my iptables rules are still intact. The next renewal is not scheduled until another (approx) 10 hours (01:26 Fri PDT)... Sooo, I think I will name that file back the way it was, and check the rules again in the morning and report back...
I checked my iptables rules again this morning, after reinstating the /etc/dhclient-exit-hooks file and the completion of a DHCP renewal... drum roll please..... Yes, the rules I added with iptables -I .... are gone, once again. I am satisfied this is not an "iptables bug".... it is either a "firestarter bug" or a case of two packages that do not play nicely together. Should this be closed as "not a bug", create a new bug against firestarter and refer back to this one? Or, change this one from "iptables" to "firestarter"? Or, everything is WAD (working as designed) and people just have to know that if they install firestarter, not to use iptables to add rules?
I'd suggest to assign this to firestarter. Maybe this is a bug.
I agree... though I think the best thing is to create a new bugzilla report, cross reference it with this one, and close this one..... I created a new bug against firestarter: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=254147 To aid with cross-referencing, I'm calling this a "duplicate" of the new bug against firestarter. *** This bug has been marked as a duplicate of 254147 ***