Package: iptables Version: 1.4.10-1 Severity: normal File: /usr/sbin/iptables-apply
If iptables-restore exits with a non-zero status, iptables-apply will NOT roll back to the original ruleset. This is not a problem if the file contains a single table (e.g. *filter ... COMMIT), because that is atomic. However if the file contains multiple tables, and the Nth one contains a bug (for example, -d does-not-resolve), the system will be left in an inconsistent state, with the first through (n-1)th tables loaded, and the remaining tables NOT loaded. The most likely scenario is *filter + *nat, but the behaviour is easy to reproduce with two *filter tables -- first loading a "paranoid" ruleset, and then loading a "featureful" ruleset. The former exists to prevent the system winding up in an "allow all" state if the latter fails to load at boot time (say, because you have installed a new kernel but not a new xtables-addons). Here is a concrete example. Suppose someone breaks local resolution of "www" and "mail" because "hey, they're in DNS, no need to put them in /etc/hosts as well". At this point, iptables-restore will load the first ruleset, "mail" will stop resolving, and iptables-restore will exit, as will iptables-apply. The first ruleset is left in place instead of the original ruleset that existed *prior* to running iptables-apply. #!/usr/sbin/iptables-apply *filter :INPUT DROP :FORWARD DROP :OUTPUT ACCEPT -A INPUT -p tcp --dport ssh -j ACCEPT # DNS lookups should fail immediately (not timeout). -A OUTPUT -p udp --dport domain -j REJECT COMMIT *filter :OUTPUT ACCEPT :INPUT DROP :FORWARD DROP -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -m conntrack ! --ctstate NEW -j DROP -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -p tcp --dport ssh -j ACCEPT -A FORWARD -d mail -p tcp -m multiport --dports smtp,submission,imaps -j ACCEPT -A FORWARD -d www -p tcp -m multiport --dports http,https -j ACCEPT -A INPUT -j REJECT -A FORWARD -j REJECT COMMIT This behaviour is actually desirable for me during boot, but I can get that by running iptables-restore. As as "safety net", I think iptables-apply should behave differently, like this: diff -ud /usr/sbin/iptables-apply /tmp/buffer-content-1489yVu --- /usr/sbin/iptables-apply 2010-10-30 03:46:48.000000000 +1100 +++ /tmp/buffer-content-1489yVu 2011-06-14 16:22:10.679281774 +1000 @@ -141,6 +141,10 @@ if ! "$RESTORE" <"$FILE"; then echo "failed." echo "E: unknown error applying new iptables ruleset." >&2 + echo "Timeout. Something happened (or did not). Better play it safe..." + echo -n "Reverting to old ruleset... " + "$RESTORE" <"$TMPFILE"; + echo done. exit 5 else echo done. Perhaps it should trap ERR and INT and rollback to $TEMPFILE in the face of *any* problem. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.38-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages iptables depends on: ii libc6 2.13-6 Embedded GNU C Library: Shared lib ii libnfnetlink0 1.0.0-1 Netfilter netlink library iptables recommends no packages. iptables suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org