Any firewall configuration software which supports portmapped services (I use firehol) must necessarily query the portmapper in order to open up access to those services. The problem is that there is currently nothing to ensure that those services are started before the firewall at boot time, and there's a good chance the firewall will start first (as it did on my system). In such cases, the portmapper will not yet know about those services and an error will be generated. At best, the firewall will fail to open those services. At worst (as in the case of firehol, and I would guess most firewall configurators), the error aborts the firewall configuration completely, leaving the machine totally UNfirewalled. This is a major bug because NFS is such a commonly used portmapped service, but certainly other portmapped services (ltsp, external famd, I think) can trigger it, as well. A general solution must be implemented to ensure that portmapped services are started before firewall configurators. Of course, the simplest possibility is for all init scripts for portmapped services to have a "before firewall" line in them (this is already a 'provide' in firehol, and I'm assuming the same is true for other firewall configurators). This is my current bandaid, and works well. Another possibility is to modify runscript so that "need portmap" automatically implies "before firewall", so that it's impossible for this mistake to be made. This might be overkill, though, because 1. some portmapped services are, by nature, localhost-only, so why delay the firewall?, and 2. implicit "magic" is confusing and bad. :) I've added devs for nfs and firehol to this bug, but it may be appropriate to add a few others, as well. I'm just not sure whom. :)
on the flip side, some people argue that they want the firewall up and running before any interface is even activated since iptables is the default firewall provider, and we've taken the route that we want that in place before net comes up, i'm going to tag this as CANTFIX since we cant satisfy both groups of people iptables-1.2.9-r1.init: depend() { before net } if you can think of a good solution (i'm certainly at a loss) as to how both groups of people can be satisified, then i'll certainly be willing to update the scripts
What about the last group? The group that doesn't want a firewall at all? We could set all policies to DROP from net if the kernel has netfilter and iptables is installed. That would mean people who don't want a firewall have to do one of three things: - not include netfilter in their kernel - not install iptables - configure the firewall to set default policies to ACCEPT Maybe that is acceptable.
Well, even in the current configuration, Firehol starts after the interface is up, so that needs to be addressed anyway, but your point is well taken. How about one of these possibilities, in order of increasing complexity. 1. A separate package called "earlyfirewall" or something that sets all policies to drop. "net.*" scripts would all be set "after earlyfirewall" (or the other way around if "before net.*" is a valid syntax), and when firehol's turn comes up, it will of course overwrite those rules with its own. portmap-based packages would all be "before firewall" as I suggested earlier. Note that earlyfirewall would NOT "provide firewall" so that it is allowed to run before all of those things. Disadvantage: everything's a drop during boot, which can cause problems for some (many?) configurations (simple example: someone using ntpdate (/etc/init.d/ntp-client) to set the date during boot). -OR- 2. firehol (and similarly for other firewall packages) installs a second initscript called firehol.boot. It uses the config file "/etc/firehol/firehol.boot.conf", which by default is a symlink to firehol.conf. This way firehol simply runs twice: once early to protect the (justifiably) paranoid, and once again after the portmapper is ready to go. If the user does use portmapped services, (s)he can remove the symlink and make firehol.boot.conf be a slightly stripped down version of the config (without those services). Again, portmapped service scripts would be "before firewall" and firehol would "provide firewall" but firehol.boot would not. Disadvantage: Two config files to maintain (but pretty much trivial, and it won't bite anybody in the behind by accident, since they have to explicitly "rc-update add firehol.boot default (or boot)" first. -OR- 3. A bit more esoteric: Similar to 2, but instead of a separate config file, firehol.boot builds its config file by concatenating the normal one onto a header which redefines every portmapped service we can think of in a harmless, non-portmapped way. Example: server_nfs_ports="udp/9" # the "discard" service port client_nfs_ports=9 Disadvantage: complexity and the corresponding *possible* error-proneness (this may turn out to work great, though). Also, not a generally-applicable solution. Notes about this: * Those concerned with the infinitessimal chance of a DoS attack through the discard service should keep in mind that A. The firewall will run in this configuration for only a few seconds, and B. You shouldn't (and probably don't) have discard running anyway and C. come on, it's UDP! :P * I picked 9 as the client port simply for consistency and because it seems wise to use a privileged port. * One should just be aware that portmapped services won't actually be reachable until the later firehol script runs. ================= 4. (My favorite now) It just occurred to me that 2. and 3. can be combined to provide the best of both worlds: firehol.boot uses a separate config, as in 2., but by default that config (rather than being a symlink to firehol.conf as in 2.) is a file that simply contains the overriding service definitions as I indicated in 3., and ends with "source /etc/firehol/firehol.conf". This default still has the caveats of 3., but provides and easy way to circumvent them and instead choose to maintain a separate firehol.boot config file in configurations where those caveats become a problem. This one seems like a pretty sweet solution for firehol in particular.
