Bug 680599

From my understanding, this is not a security issue (and it isn't a bug either; this is done by design).  Having the network start before iptables is bad form; you want the firewall in place before the network is brought up in order to prevent any kind of race condition (no window of opportunity for unprotected ports).  Having the firewall rules in place prior to the network being up insures that at no time does the system not have a firewall active.

Also, my understanding of the iptables-restore command is that it parses the saved rules as pretty much one big blob, not one command at a time (or, at least, it treats it as one command) so if iptables accepts all rules (other than those it can't handle (such as with a syntax error, etc.), then you would have an incomplete firewall.  What if there was a rule that followed that depended on a rule that was discarded?  Your firewall would be incomplete and could potentially cause very serious problems (and if this is a remote system, could prevent you from logging in to fix it).

The assumption is that the firewall rules that iptables-restore is loading were created by iptables-save, which means they are a working ruleset.  There should be no syntax errors and no DNS lookups.  So if iptables-restore cannot fully load these rules, it will report a failure (which it is doing) and not load anything (which is safest as it allows someone to login to fix things).

As a test, I added the following rule to iptables using the commandline tool:

# iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 80 --source odin.annvix.ca -j ACCEPT

then I used iptables-save to save it to /etc/sysconfig/iptables and what iptables-save wrote was:

-A INPUT -s 192.168.250.50/32 -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT

You'll note that it did not keep the hostname but turned it into an IP address.

I believe you need to use the iptables save/restore as it was intended to be used, and if you do, you won't have a problem.

If you do need something specific (e.g. for dyndns), you will probably need to add those specific DNS-based rules to /etc/rc.d/rc.local.  That will add them to the firewall later than the rest of the firewall rules, but they will get there and the static parts of your firewall will start as intended.

Keeping that in /etc/sysconfig/iptables probably isn't a great idea anyways; if the IP address of the host changes during the running of the system, the firewall will not change to reflect it since it will only store the IP address of that host in the firewall when it starts or is reloaded.  For instance:

# grep odin /etc/hosts
192.168.250.50  odin.annvix.ca odin
# iptables -L|egrep '(http|80)'
ACCEPT     tcp  --  odin.annvix.ca       anywhere            state NEW tcp dpt:http 
# iptables -nL|egrep '(http|80)'
ACCEPT     tcp  --  192.168.250.50       0.0.0.0/0           state NEW tcp dpt:80 
# perl -pi -e 's/192.168.250.50/10.1.1.1/' /etc/hosts
# grep odin /etc/hosts
10.1.1.1        odin.annvix.ca odin
# iptables -nL|egrep '(http|80)'
ACCEPT     tcp  --  192.168.250.50       0.0.0.0/0           state NEW tcp dpt:80 
# iptables -L|egrep '(http|80)'
ACCEPT     tcp  --  192.168.250.50       anywhere            state NEW tcp dpt:http 

As you can see, when the IP address changes, the firewall does not dynamically re-adjust the rules, despite having told iptables the hostname versus the IP address.  So if you need to use DNS to set these rules, you need to have them done dynamically and checked periodically.

I'm closing this as NOTABUG.  The firewall is doing exactly what it is supposed to be doing.