Re: Securing a Linux Firewall

[John McDermott <jjm () jkintl com>]

Carson Gaspar wrote:
> > Everything on the box that you don't need is a potential way for someone
> > to grab control of an executable which can cause damage.  Just because 
> > the
> > image isn't executed during init processing doesn't mean that someone
> > can't start it up some other way.

> If the binary grants no additional privileges, then it can do nothing 
> the attacker couldn't do already. If you can execute shell code, you can 
> copy bits onto the box (at your current privilege level) - assuming 
> there is at least one writable directory on the box.

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.

> So far, the only comments I've received that make sense are:
>
> - Not having the binary in the expected location prevents skript kiddiez 
> attacks from suceeding
>
> In my opinion, this provides minimal additional security. My threat 
> model is a determined attacker, not a clueless scriptoid.

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 the binary isn't on the box, nobody can enable the service by accident
>
> True. But I feel that a regular system config audit is a better way of 
> confirming that nobody's done anything unfortunate.

Yes, it is better, but I prefer to use both.

> There are a few reasons I don't like the "strip everything off the box" 
> mentality.
>
> - It frequently makes debugging problems nearly impossible, as the 
> necessary tools are not present.

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.

> - Every time a patch or a new OS version is released, the set of files 
> that are required changes. Also, new privileged binaries may appear.

Yes.  Tools like tripwire help with this.  I also tend to do
        touch /UPDATED_yyyymmdd
so I can easily do a 'find -newer'.

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

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.

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

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.

--john

--
John McDermott
Writer, Educator, Consultant
jjm () jkintl com
V +1 505/377-6293 F +1 505/377-6313

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