Re: Securing a Linux Firewall

[Carson Gaspar <carson () taltos org>]

--On Tuesday, July 23, 2002 4:01 PM -0600 John McDermott <jjm () jkintl com> 
wrote:

> This, I believe, presumes that you are *100% sure* that the given binary
> can grant no additional privs.  I am seldom that sure about software.

If it is not setuid, and not setgid, it _can't_ grant you extra privs 
(ignoring funky capability ACLs and the like).

> Then you should care even more.  Why leave something around that cen be
> exploited even if you personally don't know how to use it in an attack?
> I prefer to err on the side of caution and remove anything not needed.

If it's not running as a daemon, and grants no additional privs, how can it 
possibly be "exploited"?

> One easy solution is to create a CD of the tools you want to use.  Most
> of the debugging tools can be run from a CD with no problem.  When you
> are out of debugging mode and back to production mode, remove the CD.

Ah. Here we run into environment differences. I have a very difficult time 
intserting a CD into a box in Tokyo with no CD-Rom drive, when I'm in my 
bedroom in Manhattan.

> > I've had to maintain "jumpstart"-like images for secure servers.
> > Maintaining a "known-good" list for privileged binaries is relatively
> > straightforward. Maintaining a "known-good" list of _all_ binaries is a
> > nightmare. I further assert that maintaining a "known-bad" list is a
> > lost cause.
> I may be confused, but to me that sounds like "make a list of the few
> programs the firewall needs and only put those on the jumpstart CD". This
> means removing all unused packages from the system before creating the
> "jumpstart"-like CD.

No. "The few programs the firewall needs" is significantly larger 
(especially under Solaris) than "The few setuid/setgid programs the 
firewall needs". I assert that the first set is very large, and is very 
difficult to maintain as the OS changes. You are free to disagree with my 
assertion.

> Also consider
> - reload-time.  I like to have a ghost image (or similar) of my firewall
> (in addition to a hot copy of the disk  if there is money) so I can
> restore the firewall if it crashes.  A smaller system is easier to
> restore.

I've never had a firewall that I couldn't reinstall from scratch in under 
30 minutes. I'm sure I could make that 5 if I trimmed things, but 30 is 
fine for my purposes.

> - audit time.  It is easier to audit a system with fewer packages than
> one with lots of packages. (I am not saying, "make one big package"; I
> mean "more software is more difficult to audit".)

But you _don't_ _have_ _to_ _audit_ _everything_. Things that don't run at 
boot, and grant no additional privs, are just noise. They are inert, and 
there is no earthly reason to care about them. This is the core premise of 
my approach. All I have to audit are about 5 binaries, and a (sadly much 
larger) list of shared objects that they depend upon.

> BTW, Marcus once wrote about an idea of creating a firewall by starting
> with a kernel and just a few basic utilities and then *adding* only the
> necessary software (as opposed to removing the unnecessary).  While I
> have yet to try this, it sounds difficult but probably more secure to me.

This is the "known good" list of all binaries aproach I mention above. It 
creates unmaintainable boxes, in my experience.

--
Carson

_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards