start script fails with upstart (if config requires DNS resolv)

[ceg]

Binary package hint: firehol

ubuntu 9.10, 10.04, 10.10, ...

The failure to load with domain names used in the firehol.conf may have arisen with the network now set up by upstart's native /etc/init mechanism (instead of with symlinks in/ets/rc?.d) or been present all the time.

However, a proper fix should now be to ship firehol with specific upstart definitions and corresponding config files:

1) /etc/init/firehol-prep.conf that starts firehol (before any network/dns is up) with the corresponding config file /etc/firehol/firehol-prep.conf (by default just shutting everything down).

2) /etc/init/firehol.conf that starts firehol (always after any network interface is set up) with the regular /etc/firehol/firehol.conf

Symtoms (with domain names used like in "client http accept dst archive.ubuntu.com"):
 * /etc/init.d/firehol script is there
 * /etc/firehol/firehol.conf is in place
 * firehol can be started with "/etc/init.d/firehol start" (START_FIREHOL in /etc/defaults/firehol is set to yes) and the iptables are set ok.
 * symlinks in /etc/rc?.d do exist

However, after a reboot the chains are empty:

# iptables iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Solution:

Load only a basic (blocking) config file with numeric IPs in the early boot process,
and (re)load the real firehol.conf later, each time a network device got set up.

Workaround:
Call "firehol /etc/firehol/firehol.conf start" again from /etc/rc.local.

(Warning: System is without protection until a successful firehol start.)

[Johnathon (kirrus)]

Duplicated the wrong way round? Surely the newer ticket should me made a duplicate of the older ticket?

Still, marked as security vulnerability. Not having a firewall after bootup is a security risk.

[Johnathon (kirrus)]

s/me/be/ :)

[ceg (ceg)]

AFAIK the firehol init script is present and has not changed.

The suspecting package IMHO may well be an incomplete/broken upstart / -compat init procedure.

[ceg (ceg)]

maybe related: http://sourcecode.de/content/fun-upstart

[ceg (ceg)]

Johnathon, can you reproduce this bug?

[Johnathon (kirrus)]

ceg wrote:
> Johnathon, can you reproduce this bug?
>

No... with a basic firehol setup, firehol is starting on bootup, and
correctly loading rules into iptables...

[ceg (ceg)]

Didn't mention this is on a *fresh* 9.10 installation.

[Johnathon (kirrus)]

ceg wrote:
> Didn't mention this is on a *fresh* 9.10 installation.
>

mine is a beta-release fresh install. Kept it up-to-date, obviously.

Asked an old friend if he'd seen any problems, and he hasn't, running
9.10 with firehol.. sounds like it might be a problem just with your
machine or setup :/

[ceg (ceg)]

I got the firehol output into a file by modifying the init script.

The iptables commands fail because domains are not being resolved to ip addresses.

Now I am not sure. Starting the firewall before the network is up might be adequate behaviour. How can the init scripts handle this? Do firehol save on shutdown and a restore early on during boot, and a regular restart later on?

[ceg (ceg)]

This failure to load with domain names in the config may have arisen with the network now set up by upstarts native /etc/init mechanism (instead of with symlinks in/ets/rc?.d) or been present all the time.

However, a proper fix should no be now to ship two firehol upstart definitions:

One /etc/init/firehol-first.conf (or -prenet, -init, -predns or -minimal?) definition that stats firehol (before any network/dns is up) with a corresponding /etc/firehol/firehol-first.conf .

And one /etc/init/firehol.conf definition that starts firehol (always after a network interface has come up) regulary.

[ceg (ceg)]

Sorry typo has made it unclear: I mean "a proper fix should now be to..."

[Nahsei (luispmoreira3993)]

I don't have this kind of problem... After editing properly the config file, firehol works fine.

[ceg (ceg)]

Nahsei, do you use lines like "client http accept dst archive.ubuntu.com" and the domain names are being resolved and firehol started correctly on boot?

[Phil Whineray (pdw-slightly-cracked)]

At the risk of courting contreversy, is the real "solution" not to only use IP addresses in firehol scripts and possibly better failsafe if the firewall does not load (although good look googling for the reason or remotely logging into your box to fix it with everything set to deny).

Using names means any resolution failure risks your firewall not starting up; the fact that DNS is apparently no longer resolving early enough in the boot process has simply exposed one cause.

The fact is that when using a domain name IPs are resolved at load time and will be unchanged for the lifetime of the firewall - so it doesn't do what most people would really want anyway.

[ceg (ceg)]

Actually right, resolving at each startup makes the firewall vulnerable to dns spoofing.

OTOH its a nice feature to be able to write down domain names.

So, the two stages may be improved.
The lower-stage firehol start/stop scripts could always just dump/restore the rules (resolved IPs), to make sure firewall is up even on resolv errors.
The stage two script (when an interface came up) rechecks whether the config file (possibly containing domains) does still create the same rules (with IPs).
If there are differences, notify/warn the admin if the config file has not been changed.

[ceg (ceg)]

for dumping rules see man page "firehol save"