Re: Securing a Linux Firewall

[Carson Gaspar <carson () taltos org>]

--On Thursday, August 01, 2002 6:42 PM -0700 "Stephen P. Berry" 
<spb () meshuggeneh net> wrote:


> In short, if you're interested in securing the box, you're either already
> doing much of the work required to come up with a minimal install or
> you're not actually securing it.

No. Doing an basic application security analysis does not require doing the 
full filesystem dependency analysis. And in reality, doing so is not 
possible, as you cannot know all the dependencies in a closed-source 
product unless you can fully excercise all functions.

> So you tell me.  If you're actually trying to secure these tens of
> thousands of boxen, what're you doing?  Run a generic hardening script on
> all of them? What are you doing to insure the security of the veritable
> plethora of individual applications you say you're adding, and how are
> you testing the interactions of multiple applications?  Gimme a quick
> _precis_ of your methodology.  I'm not looking for a set-by-step guide or
> trying to hang you up on some detail---I'm just looking for something of
> roughly the same level of detail as has been offered by the `minimal
> install' side of the discussion.

I gave it at the beginning of this thread, but I'll give a precis:

- Do an OS install. Whatever packages float you boat. I usually just do a 
full install, unless I'm tight on disk space. (This should be automated, 
and version-controlled, in any non-tiny environment)

(The following is all parameterized (both known-good and known-bad) and 
scripted, and must be re-done after any OS patches)

- Strip all privilege escalations (setuid, setgid), and make sure 
everything is owned by root:sys (or your OS's equivilant), and not world or 
group writable. The exceptions to this should be few and far between.

- Disable the start scripts for all un-necessary daemons (which should be 
almost all of them)

- Turn logging to 11

- Do OS-specific hardening stuff (for Solaris, turn on non-executable 
stacks, etc.)

Ta-da, you have a base OS. When Sun releases a new version of the OS, 
Install it and run the script. It spits out warnings about Bad Stuff it 
doesn't know about. Investigate, and add said stuff to the known good or 
known bad list.

For each service you want to run, install said servcice. Run the script. 
See what setuid,setgid,non-root/world/group-writeable crap it installed. 
Add to the known good or known bad list. Then do the app-specific security 
config (which hopefully involves chroot, and a non-privileged account). 
Package the whole pre-configured thing and add it to the list of options 
for your build process.

> > [...]is too high for the minimal security gained from it. Nobody has
> > given me sufficient evidence of either great security gains, or of
> > reduced  maintenance costs, for me to change my assertion.
>
> Out of curiosity, what -would- be sufficient?  Okay, you've got `easier
> to maintain' in the other column.  What, to your mind, would be sufficient
> to counter the argument from convienience?  Be specific.  Use
> examples.  20 points.

The only arguments for not having de-fanged binaries on a system I've heard 
are:

- Admins can't make mistakes and enable bad stuff if it isn't there
- Skript Kiddiez are too dumb to use a buffer overflow to write their own 
copies of stuff to disk
- Applications could invoke bad stuff if it's there

The additional security you gain, given the above, is almost non-extant. 
Especially if your threat model is a determined attacker.

What would convince me? Show me a vulnerability that is exploitable on my 
system that isn't on yours.

> That being said, I think one of the strongest positive, technical
> arguments that can be made for minimal installs is that they aid greatly
> in the containment of an exploit.  Watch actual compromises and pay
> attention to what the evildoer is doing.  A `minimal' install severely
> limits the ability of the badguy to turn his breakin into an event of
> wider operational significance.  If it doesn't prevent it outright, it
> hampers his ability to cover his tracks or expand his success.  The
> average badguy's timetable for expanding from a compromise on a
> perimeter-adjacent machine is typically on the order of a ksec or so.
> Comparatively few organisations have response times on the same order.
> Being able to equalise these timeframes is a Big Win.

Any attacker with half a brain can install any tool he wants on the box, 
once he's on the box. Yes, having a compiler installed makes his life 
easier. But not having one doesn't stop him. It may indeed slow him down. 
So would running VMS.

All the arguments for having a minimal install involve "raising the bar" 
and making an attacker's life more difficult. But it also makes the admin's 
life more difficult, in a real and monetarily measurable sense. And doesn't 
prevent a determined attacker from doing anything.

--
Carson

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