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

Agreed.

> *snip*
> (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*

No comment.  

> #3. Handling service daemons is slightly more complex in that each is
> likely to need a few rules of it's own.

Oh, yeah...

>   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
(406) 581-0495



More information about the hlfs-dev mailing list