netfilter firewalling problems and solutions
ken_i_m at elegantinnovations.net
ken_i_m at elegantinnovations.net
Wed Feb 18 18:43:30 PST 2004
On Tue, Feb 17, 2004 at 11:09:05AM -0600, Dagmar d'Surreal (dagmar.wants at nospam.com) wrote:
> #1. Netfilter needs to implement a deny-by-default policy
> (I should probably break this last bit out
> into it's own justification bullet-point)
Yeah, we definitely need to iron out the details regarding
../init.d/network The solution to this point may fall out of point 3.
> #2. *snip*
> #3. Handling service daemons is slightly more complex in that each is
> likely to need a few rules of it's own.
> While it might seem more convenient to lob all of these rules into one
> script so they are all in the same place, their existence is atomically
> tied to the active presence of a service daemon. For this reason we're
> better off putting rules to allow each activity into the init.d script
> for that daemon.
Disagree. To make it work "lob" is not a verb that leads to a good
solution but breaking the firewall up into pieces and sprinkling it over a
number of daemon init scripts is not conducive to sanity.
> #4. Admins may use the kill command to stop daemons, or they may die,
> and be started (quite properly) by invoking init.d/whateverservice
> start, while firewalling rules are already present to allow their
> traffic, duplicating existing firewalling rules.
Richard Downing is working on a runit scheme that may buy some leverage.
> #5. Something may have broken and netfilter may not currently be
> available for the kernel on boot-up (administrator error, filesystem
> corruption, malicious user, etc), leaving the possibility that services
> may start without firewall rules to limit their access.
> This is a pretty serious issue. For this reason, we should probably
> be checking the exit status of all rule insert/appends (although not for
> any rule deletions or flushes, since these can exit with non-zero status
> without actually indicating a show-stopper)
Actually, I borked a firewall and ended up locking myself out. I had
to get a noc monkey to bump the reset switch so I could get back in.
> ...however the machine
> should not _stop_ booting entirely, but continue so that the
> administrator can login to a console to fix things.
Yes, it's important to not stop the box from booting. I remote admin and
to get around the "login to a console to fix things" I set a cronjob to
revert/reboot if I am unable to get in and stop it.
> #6. *snip*
Obviously I have some reading to do to get caught up on the current state
of netfilter. Then I hope to have some constructive input for item 3.
> *1 - At some point, some right-thinking person might wish to simplify
> some of this by putting together a wrapper script that takes less arcane
> options to create filtering rules, like `scriptname allow echo on
> eth0`. If they want to see it adopted by lots of people, the surefire
> thing will be to add something a bit more complex than the norm so that
> a new /etc/service-groups file can be scanned to facilitate something
> like service *groups* named http-server, http-query, dns-server,
> dns-query, ping, etc which would need otherwise require multiple rules
> at a time. hint hint *kof*I'm too qlazy*kof* hint hint
I am not sure what you are hinting at (besides the obvious that you would
like to see someone else do the work).
I think, therefore, ken_i_m
Chief Gadgeteer, Elegant Innovations
Founder, Bozeman Linux Users Group
More information about the hlfs-dev