Bug 448906 – net-firewall/iptables-1.4.16.3 upgrade does not preserve state matches

• Product: Gentoo Security
• Status: RESOLVED OBSOLETE

[Description Michael Orlitzky 2012-12-27 19:02:15 UTC]

This was mentioned by Graham Murray on gentoo-user and I've just confirmed. The old --state matches were deprecated in favor of the new conntrack stuff, and when upgrading, your old state rules get clobbered.

Steps to reproduce:

  # emerge -1 =net-firewall/iptables-1.4.13
  # sudo iptables -A INPUT -p ALL -m state --state NEW,INVALID -j DROP

This should disallow new and invalid connections.

  # iptables -L -n
  Chain INPUT (policy ACCEPT)
  target     prot opt source               destination         
  DROP       all  --  0.0.0.0/0            0.0.0.0/0            state INVALID,NEW

  Chain FORWARD (policy ACCEPT)
  target     prot opt source               destination         

  Chain OUTPUT (policy ACCEPT)
  target     prot opt source               destination

Now upgrade to iptables-1.4.16.3:

  # emerge -1 =net-firewall/iptables-1.4.16.3

The state rule is now broken:

  # iptables -L -n
  Chain INPUT (policy ACCEPT)
  target     prot opt source               destination         
  DROP       all  --  0.0.0.0/0            0.0.0.0/0           state 

  Chain FORWARD (policy ACCEPT)
  target     prot opt source               destination         

  Chain OUTPUT (policy ACCEPT)
  target     prot opt source               destination

The same thing happens if we try to -j ACCEPT connections of state ESTABLISHED or RELATED. So while I'm not sure how iptables will handle this, one case or the other is a problem.

We *definitely* need a big warning for this.

[Comment 1 Michael Orlitzky 2012-12-27 19:17:32 UTC]

I just realized the fix may not be obvious, so here it is: recreate all of your state rules and then save them. I have an iptables-config script that does this, and even with the old --state matches it works (albeit with warnings).

The new iptables will convert these rules to conntrack rules, at which point it's safe to `/etc/init.d/iptables save`.

[Comment 2 SpanKY 2012-12-27 21:19:37 UTC]

we could add an elog, but i'm not sure we'd add anything else

[Comment 3 Michael Orlitzky 2012-12-27 21:39:14 UTC]

(In reply to comment #2)
> we could add an elog, but i'm not sure we'd add anything else

With my particular set of rules, I wouldn't see it, because my SSH packets will be dropped.

[Comment 4 Michael Orlitzky 2012-12-28 16:46:12 UTC]

I have two groups of people in mind:

1. People who admin over SSH and will have their connections dropped after the upgrade. Those people won't be able to see an elog, and they may have a huge hole opened in their firewalls until they can physically get to the server to fix it. Or maybe there's no hole, because everything is blocked, and they have to get to the server to fix /that/.

I fit into this category, and was lucky that someone was nice enough to point out the breakage before it happened.

2. Those people who either admin locally, or whose SSH rules will keep working after the upgrade. They're able to see the elog, but it's kind of rude to have an elog that says "Hey, we just broke your firewall, we hope you remember what the rules were!" You can't fix it easily without knowing which rules to recreate. While they scramble to figure out what to do, they might have a hole in their firewall. Or everything might be down.

Before the upgrade, you can just dump your iptables state and see which state rules you've got. After the upgrade, you can recreate them and everything will be OK (if your SSH connection didn't just get dropped). But if you don't know to look beforehand and you upgrade, the rules get clobbered and you have to know what they were to fix everything.

The proper fix, before it breaks, is to replace all of your state matches with conntrack matches, and `/etc/init.d/iptables save`. Then the upgrade works normally. But you can't do this unless you know about it beforehand.

[Comment 5 Michael Orlitzky 2013-01-02 20:09:23 UTC]

Adding to the discomfort, ones potentially needs to recompile his kernel. Newer iptables requires NETFILTER_XT_MATCH_CONNTRACK, whereas the old state matches used NETFILTER_XT_MATCH_STATE.

[Comment 6 SpanKY 2013-04-27 21:30:56 UTC]

could you post the phrasing you'd like to see in the elog ?

[Comment 7 Michael Orlitzky 2013-04-27 22:15:06 UTC]

(In reply to comment #6)
> could you post the phrasing you'd like to see in the elog ?

It's pointless now. Three months later, everyone's state rules are long gone. User action was required *before* the upgrade.

[Comment 8 SpanKY 2013-04-28 01:09:28 UTC]

so it goes