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
