Summary: | init scripts for portmapped services (such as nfs) must run before firewall init scripts (such as firehol) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Mike Nerone <mike> |
Component: | Current packages | Assignee: | Network Filesystems <net-fs> |
Status: | RESOLVED CANTFIX | ||
Severity: | critical | CC: | centic |
Priority: | High | ||
Version: | 2004.0 | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Mike Nerone
2004-08-07 12:19:13 UTC
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. |