init script starts before NFS, NIS, DNS (need two stages)

[Xavier]

Booting the server, the firehol script starts before NFS and NIS (if these were installed), and rollback iptable loading and exits leaving the iptables table empty.

Explicity firehol needs to be restarted (or started) after NFS and NIS (possibly more services need this too, I don't know...)

Movin the S41firehol script from rcS.d to the rc2.d runlevel solves the problem.
I don't know if this is a correct solution or not....

This happens in Ubuntu breezy and firehol 1.231-2

[Daniel T Chen (crimsun)]

As of 8.10, this source package needs corrections to:

debian/init.d/firehol
debian/postinst

The revised TearDown spec should be adhered to. Further, the script must be modified to start no earlier than 46 (cf. /etc/rcS.d/S46mountnfs-bootclean.sh) and likely needs to busy-wait [unless a newer upstart semantics is used].

[Jonathan Marsden (jmarsden)]

Daniel, can you explain your reasoning a little more, please?

I started to look at fixing this, and have some questions...

Firstly: In Intrepid (firehol 1.256-3) the debian/postinst script does:

  update-rc.d firehol start 41 S . start 36 0 6 . > /dev/null

I initially suspected a typo: the second "start" should be "stop". Am I correct? Why start a firewall when rebooting or shutting down? Or, is this a "clever" way to ensure the firewall is only stopped very late in the set of scripts run at shutdown/reboot, after all other applications are stopped, since Debian Policy Manual 9.3.1 says:

    The two runlevels 0 (halt) and 6 (reboot) are slightly different. In these runlevels,
    the links with an S prefix are still called after those with a K prefix, but they too
    are called with the single argument stop.

A comment in the postinst script describing the author's intent would perhaps have been helpful, given how complex the update-rc.d option syntax is.

Secondly: If this postinst script is patched to say something more conventional, based on
https://wiki.ubuntu.com/Teardown, such as

  update-rc.d firehol start 46 2345 . stop 54 1 . > /dev/null

is that sufficient to solve this bug? If busy-wait is required, what is the firehol init script supposed to wait for?

Thirdly: I fear that delaying firewall setup until runlevels 2 to 5 may introduce a serious security issue. Does it really make sense for a firewall to wait until remote network filesystems are mounted before it is started? Doesn't that introduce a potentially lengthy window of opportunity (between network startup and completing of remote filesystem mounts) during which time networking will be active, but the machine will be unprotected by the packet filter?

In this case, perhaps the real solution would be for NFS/NIS client machines to use a firehol script (on a local fileystem!) that allows the appropriate NFS/NIS traffic to flow, and then to start firehol *before* any attempts to do remote filesystem mounts are made? So the current approach of starting it in /etc/rcS.d/ is then correct?

I think that (other than the start/stop possible typo issue mentioned above) this reported bug may in fact be a policy question -- the firehol developers went for security, starting the packet filtering early; the bug reporter apparently wants a shared firehol policy file, and so wants the firewall enabled later, only after NFS/NIS are up and running. Which approach is "correct" perhaps depends on your perspective (and your degree of network security paranoia)?

Since anyone installing a firewall on their machine is being at least somewhat security-conscious, "secure-by-default" sounds to me like the better way to go here, leaving those who want to reduce security to allow the convenience of an NFS-shared firehol script to make that choice for themselves (using any of several runlevel editors) and be very ware of the risk they are taking.

Jonathan

[ceg (ceg)]

firhol should be made to source firehol.conf and parts from a directory like /etc/firehol.d, where other packages can drop config snippets.

While firehol still sets up the firewall as early a possible in the boot up process.

[ceg (ceg)]

Does what the reporter posted mean that NIS/NFS scipts are flushing iptables?

[David Stansby (dstansby-deactivatedaccount)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. We are sorry that we do not always have the capacity to look at all reported bugs in a timely manner. There have been many changes in Ubuntu since that time you reported the bug and your problem may have been fixed with some of the updates. It would help us a lot if you could test it on a currently supported Ubuntu version. When you test it and it is still an issue, kindly upload the updated logs by running apport-collect 28906 and any other logs that are relevant for this particular issue.

[Phil Whineray (pdw-slightly-cracked)]

I appreciate this is not a direct reference to firehol, but I have put together a patch for my fork, sanewall, see here:

http://lists.sanewall.org/pipermail/sanewall-dev/2013-March/000042.html

If anyone is able to help test + verify the principle idea I can extend the change to cater for early NIS and DNS so that no special infrastructure to do multiple runs is needed.

The patch can in theory be backported to firehol although it does depend on some earlier patches.

[Mattia Rizzolo (mapreri)]

since the were no reply in more than one year I'm closing the bug report (even to drop the bug from the list)