Secure testing team - May 2012 - Bug#672296: iptables-persistent: dangerous start/stop runlevels

Package: iptables-persistent
Version: 0.5.3+nmu1
Severity: important
Tags: security


Hi.

I think the current start/stop run levels are quite dangerous.

I should have marked that bug as serious/grave, especially as iptables can
easily be the crucial point for securing a system.
Consider rules that demand from packets to come via IPsec (thereby giving
security) that allow access/control to/of the system.


stop (now 0 1 6):
- I don''t think iptables should be ever stopped, in the sense of
  clearing the rules set up by the user.
  Especially as it''s totally undefined what "stopped" means.
Is it allow all?
  Is it deny all but traffic on loopback?
- It''s further not guaranteed that there is no networking in single
user mode.
  So stopping it for run-level 1 may open holes.
- Does it make sense at all to stop it on 0/6? I don''t think so, at
least unless
  the chains are stored.
Suggestion: Go back to the previous (safe) default of
# Default-Stop:


start (now 2 3 4 5):
- Again "S" was safer default, though not perfect.
- Networking may already take place in runlevel S, which is now (even more)
  unsecured.
- Starting this in 2 3 4 5 means it can be started basically at and time
  during these runlevels.
  But other services may already depend on iptables rules in place.
  My own example is that of depending on rules to be in place, that
  allow only IPsec connections to/from certain destinations/sources.
  These connections are used by level 2/3/4/5 services, e.g. ejabberd.
  With the new runlevels 2/3/4/5 of iptables-persistend it''s not
guaranteed
  at all, that it runs before ejabberd comes in place.
  Even worse, giving that people usually allow ESTABLISHED connections,
  such a pre-iptables-rules-loaded connection may stay forever unsecured.
- Typically other services don''t depend on iptables-persistent.

On can now argue, that other services should depend on itpables-persistent.
This is tempting, but a) it''ll probably just never happen that this is
adopted
b) it always leaves the gap that some new package misses this, especially
as there are so many "firewall" packages in Debian.

Suggestion: Go at least back to:
# Default-Start:     S

This alone is not enough in principle, as netwokring may already take place in
run level S.
The best solution would be, if iptables-persistent could reverse-depend
on the networking initscript.
But I guess this is not possible, as iptables rules cannot be loaded before
networking runs, right?
So we need another way to secure, that iptables-persistent comes directly
after networking.


Cheers,
Chris.