Bug 253877 - iptables has amnesia
iptables has amnesia
Status: CLOSED DUPLICATE of bug 254147
Product: Fedora
Classification: Fedora
Component: iptables (Show other bugs)
7
All Linux
high Severity medium
: ---
: ---
Assigned To: Thomas Woerner
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-08-22 11:47 EDT by Don Russell
Modified: 2007-11-30 17:12 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-24 09:53:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
output from sh -x /etc/init.d/iptables save >& log1 (3.76 KB, text/plain)
2007-08-22 19:22 EDT, Don Russell
no flags Details
output from sh -x /etc/init.d/ip6tables save >& log2 (3.75 KB, text/plain)
2007-08-22 19:23 EDT, Don Russell
no flags Details

  None (edit)
Description Don Russell 2007-08-22 11:47:31 EDT
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
Comment 1 Thomas Woerner 2007-08-22 12:03:57 EDT
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
Comment 2 Thomas Woerner 2007-08-22 12:18:04 EDT
"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?
Comment 3 Don Russell 2007-08-22 18:37:37 EDT
(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
Comment 4 Don Russell 2007-08-22 18:42:14 EDT
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.
Comment 5 Don Russell 2007-08-22 19:22:03 EDT
Created attachment 164591 [details]
output from sh -x /etc/init.d/iptables save >& log1

output from sh -x /etc/init.d/iptables save >& log1
Comment 6 Don Russell 2007-08-22 19:23:21 EDT
Created attachment 164592 [details]
output from sh -x /etc/init.d/ip6tables save >& log2

output from sh -x /etc/init.d/ip6tables save >& log2
Comment 7 Thomas Woerner 2007-08-23 04:00:06 EDT
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?
Comment 8 Don Russell 2007-08-23 09:32:51 EDT
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"
Comment 9 Thomas Woerner 2007-08-23 09:38:58 EDT
Yes, please check if it helps.
Comment 10 Don Russell 2007-08-23 18:13:23 EDT
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...
Comment 11 Don Russell 2007-08-24 09:29:39 EDT
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?
Comment 12 Thomas Woerner 2007-08-24 09:32:35 EDT
I'd suggest to assign this to firestarter. Maybe this is a bug.
Comment 13 Don Russell 2007-08-24 09:53:34 EDT
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 ***

Note You need to log in before you can comment on or make changes to this bug.