/etc/init.d/iptables reload flushes the netfilter tables, then loads new rules. It makes my system unresponsible, because my default policy is DROP. When the tables are flushed, the policy remains DROP and there are no rules, so no packets can reach my node. It makes a remote YP/NIS server unavailable, so getpwent and other nss calls hang forever and /etc/init.d/iptables script does not proceed to iptables-restore. Reproducible: Always Steps to Reproduce: 1. Set up a YP/NIS client and use remote /etc/passwd, /etc/shadow and probably some other domain-wide files 2. Set up iptables, so you only accept the packets you need and the default policy is DROP 3. Run /etc/init.d/iptables reload Actual Results: The /etc/init.d/iptables script does not proceed to iptables-restore line, so the node becomes totally unreachable over network. If you do it over an SSH session, you will lose control. Expected Results: The /etc/init.d/iptables reload should set policy to ACCEPT before flushing the tables and restoring the rules.
This behaviour is intended as explained on Bug 21801; and your suggestion sounds like a rather bad idea to me security-wise. Imagine you try to reload rules from a screwed up file and it fails... You are accepting every connection now, yay. :P
Created attachment 135816 [details] workaround a replacement for /etc/init.d/iptables
(In reply to comment #1) What about saving current rules to some tmp file and restoring them, if loading failes?
please attach a diff and never a complete replacement. I think the following would be a reasonable route: 1. backup the current rules -> $A 2. start a notty sub-shell (that will complete the following set of actions, and not die on disconnect). 3. remove current rules 4. install new rules 5. If failure in #4, wipe rules, restore $A
(In reply to comment #4) iptables-restore may fail if there is no network connectivity, for instance, on this rule: [0:0] -A OUTPUT -m owner --uid-owner roganova -p tcp -d 62.117.90.22 --dport 22 -j ACCEPT It will be unable to resolve username into a UID without YP/NIS server. There also should be some kind of a timeout, which will kill iptables-restore and revert old rules, reporting a failure.
iptables is meant as a quick entry point, not an all-in-one solution. if it is inadequate for your needs, use something else. i dont want this script to handle every single case out there, i want the script to basically save/restore rules and that is it.
(In reply to comment #4) > 1. 2. 3. 4. 5. ... We could provide separate script for this. Currently the sysadmins have to write such scripts by themselfs and run it from screen. Is update-iptables good name? Also I'm thinking about two possible options, how to provide new rule set: * iptables rules file and load rules with iptables-restore * script to run iptables and fill in rule set. Script should return 1 on error 0 on success Also it's good idea to add some timeout after which previous rule set will be loaded if user do not interrupt script. This prevents from loosing remote control over server. Anything else I forgot. Is there any interest in such script?
i'd suggest looking at using eselect as the basis if someone wants to develop and maintain an iptables admin script (instead of simply using a real firewall script package), they are certainly free to do so if you want to do it as a sep package, the best of luck, but if you want to integrate it into the iptables package, it will need at least one dedicated maintainer as the first time a bug comes up and there is no maintainer, i'll simply drop it
Reopening, to reassign on myself.
Created attachment 180128 [details, diff] Simple test for the case where iptables-restore WILL result in a failure and loss of remote access After losing remote access to a headless machine one too many times I made the following modification. The stock script 'reload' will always result in a lockout for poorly written rules. It's not a catch-all problem solver for iptables but does help when erroneous changes are made & not tested by aborting the reload.
(In reply to comment #10) > Created an attachment (id=180128) [edit] > Simple test for the case where iptables-restore WILL result in a failure and > loss of remote access > > After losing remote access to a headless machine one too many times I made the > following modification. > > The stock script 'reload' will always result in a lockout for poorly written > rules. It's not a catch-all problem solver for iptables but does help when > erroneous changes are made & not tested by aborting the reload. > ... without compromising security by changing the default policy to "accept" and leaving the machine wide open. (yes, diligent admin will of course have tested the rules by hand BEFORE attempting reload. But just in case)
(In reply to comment #10) thanks, this looks perfectly reasonable
should be all set now in the tree; thanks for the report! Commit message: Add a "check" option and use it before reloading in case the rules are broken somehow http://sources.gentoo.org/net-firewall/iptables/files/iptables-1.4.13-r1.init?r1=1.2&r2=1.3
Thank you for the follow up.
