Re: Securing a Linux Firewall

["Stephen P. Berry" <spb () meshuggeneh net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Carson Gaspar writes:

> As a matter of curiosity, what is your experience? Platform, types of 
> applications supported, number of systems/users? This is a serious question 
> - it could be that our viewpoints are both valid, but for different 
> environments.

Well, I'm not going to post a resume unless you're hiring, but I've
done mad scientist level design and administration in environments ranging
from six-man startups to multi-billion dollar biotechs with offices on
multiple continents---and I'm pretty familiar with the pains involved
in an organisation's transition between the former case and the latter.
So I don't think my experience (or some posited lack of it) explains our
difference of opinion.


> My experience with maintaining Solaris builds for tens of thousands of 
> machines running just about anything you can imagine contradicts your 
> statements.

Several points:

        -If you're using some sort of automated package management
         to maintain all of these boxen, then the complexity of the
         `minimal install' problem is governed by the number of packages,
         not the number of boxen[0]
        -If you're trying to harden a box running some application foo,
         you either become familiar with the capabilities and requirements
         of foo, or you aren't really hardening the box
        -If you are deploying foo to a hardened box, you have either
         done a risk analysis or you are making a nonzero number of mistakes
         placing the exercise beyond the scope of this discussion.
         If you have done the risk analysis and the bulk of the information
         you need for tweaking your minimal install to support foo hasn't
         been gathered as a part of the analysis, you probably haven't
         really done a risk analysis[1]
        -If you have neither done a risk analysis nor attempted to harden
         the box running foo, then it doesn't really apply to our conversation.
         Whether or not you -should- be doing either of these things is a
         separate argument

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.

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 currently have this picture of a network that I would barely expect
to act deterministically, much less securely.


> My assertion is that the maintenance cost of maintaining a "minimal" build, 
> or multiple "minimal" builds (minimal for what? A firewall? A Sybase 
> server?),[...]

Minimal for whatever the box is doing, presumably.  Typically, I just
generate a list of components required for a each service that needs to
be supported.


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


As I mentioned before, I believe your argument is exactly backwards---in
the same way the old `default allow' rules were backwards.  A widget (binary,
library, whatever) needs to justify its presence---the administrator shouldn't
have to argue to justify its absence.

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.






- -spb

- -----
0       If you're actually trying to administer tens of thousands of
        machines---and harden them---by hand, that's a whole other argument.
1       I'm not saying a risk analysis -must- include constructing the sort
        of minimal install I'm talking about.  Rather that the risk analysis
        should include things like an analysis of required configuration
        changes, interactions with other components, and that sort of
        thing---and that these sort of things apply directly to making a
        minimal install.  I.e., the cost of creating such an install given
        a risk analysis will be significantly less than the cost of doing
        it from scratch.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (OpenBSD)

iD8DBQE9SeKdG3kIaxeRZl8RAnnZAKCppKGcjQJsOpzXvtWYOgHZmWXFFACdEHf5
60MDaZ7cU7MsF2Xndwfw9l0=
=jlFs
-----END PGP SIGNATURE-----
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards