netfilter firewalling problems and solutions

Dagmar d'Surreal dagmar.wants at nospam.com
Thu Feb 19 09:52:03 PST 2004


On Wed, 2004-02-18 at 20:43, ken_i_m at elegantinnovations.net wrote:
> 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.

I was under the impression that since this stuff is likely to be
implemented on a piece-by-piece basis (i.e. the admin is going to
install and configure named, then install and configure squid, etc),
that it's not going to be any particularly big problem (for someone
putting together a service firewall for example), since they're going to
know exactly where the rules appropriate to each service are located. 
If they can't look at the output of iptables -L and understand it, then
they've got bigger problems.

> > #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.

This could be useful. 

> > #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.

Being able to back out changes like this practically requires one to
adopt a package management system of some sort, and is going to be
mentioned explicitly once I get around to explanation of why people
should be separating the build process out and onto some other machine. 
(In practice, there's also no real need to have an entire compiler suite
on one's firewall, unless you want to help script kiddies put together
their rootkit.)

> > #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).

Well, there is _that_, but what I was mainly referring to is that many
services are going to require more than one rule to function, and
there's a lot of people who just don't know the true scope of a some of
the protocols they're using.  For example, there's lots of people out
there who don't realize that a nameserver needs to have port 53 traffic
not just over UDP, but over TCP as well, and people who've never read
the DHCP RFC would likely be shocked to know that it needs ICMP to
function properly.  Being able to describe some rules by function rather
than by raw port number could reduce administrative error.
-- 
The email address above is phony because my penis is already large enough, kthx. 
              AIM: evilDagmar  Jabber: evilDagmar at jabber.org




More information about the hlfs-dev mailing list