Re: Protecting publicly reacheable servers (e.g. HTTP)?

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

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


Adam Shostack writes:

> On Sun, Nov 25, 2001 at 10:52:44PM -0500, Marcus J. Ranum wrote:
> | ark () eltex ru wrote:
> | >I am still trying to figure out how to prevent data-driven attacks
> | >on proxy level.

> | I don't think it can be done. The only chance is to be super
> | restrictive in what you accept - to the point of accepting
> | nothing. If you do that, you generally defeat your objectives
> | if you're trying to actually exchange information with
> | someone. :(

> That you can't succeed is no reason not to try.  :)  You just have to
> be clever about what you try, and acknowledge that it will have
> limitations.
> In this vein, I think stackguard is a useful tool, as are RATS and
> ITS4.

Maybe it's just my bad attitude acting up (the holiday season does that
to me), but I think the information security industry(-ies) would be
a hell of a lot better off if we had fewer cure-all salesmen and more
fatalists.  If we spent less time trying to work around fundamental
(and almost certainly intractable) design issues and more time designing
for and controlling failure modes, I think we'd all spend less time
sending form letters to compromised ISPs and .edu admins and more
time playing xtank(6) and downloading porn[0].

I'm not saying that making services less expoitable is a Bad Thing, and
I'm not suggesting that things like StackGuard aren't valuable.  I will
say, however, that if having your externally-exposed mail server
compromised is a major crisis, you've probably made some GCEs[1]
in designing your network(s).

I won't try to outline cases and contingincies (although I'm always
willing to discuss them if someone's interested), but for most common
(and commonly-exploited) services the scope of your exposure in the
event of a compromise should be relatively small.  In somewhat
simplistic terms, you shouldn't be losing[2] anything more than what
is currently queued at the time of the compromise[3], plus your
costs of recovering from the compromise.  If the latter isn't very
small, you're probably doing something wrong.

Let's look at it another way.  Say that we can specify some ficticious
scale which indicates how secure a service/some box/a network/your job
is, stated as a percentage of what you can possibly do.  At the low
end is 0% secure.  In this context, that would equate to taking no
special action.  At the other end, there's 100%, which is every damn
thing you could possibly do.  Maybe that's a government standard 9" air
gap.  Maybe that's burning joss sticks and consulting a magic eight ball.
This is a relative scale, so it's going to be a function of things like
what your budget is and how well The Mgmt. likes your ideas.  Note that there
is not necessarily a simple relationship between our scale and the chances
of compromise[4].

In most cases you'll find that the vast majority of your resources (for
example your budget) get expended in the last five to ten percent of
this scale...regardless of what the high-end of the scale entails.
My observation is that for the cost of that last five to ten percent
of your possible `prevention' budget, you could buy a hell of a lot more
in terms of real-world security if you spent it on containment and
remediation instead.

In general, I'd rather spend my time figuring out how I'll know if
my web server is compromised, and how I'll recover from such a compromise,
than trying to come up with more ways to prevent my web server from
being compromised in the first place.  Why?  Because it is going to
get compromised, eventually.  Even if I'm a good admin, full of clean living
and righteous thoughts, if I keep up on the patches, read BugTraq
daily, don't use GUIs, watch the logs, keep regular backups, and
all the other Habits Of Highly-Successful Sysadmins...the smart money
still says that something I'm responsible for will get taken down sooner
or later.  If you could double the mean time between comprimises,
halve the mean downtime per compromise, most people would be better
off choosing the latter[5]...but almost every product, paper, and
pontification involving information security stresses techniques to
accomplish the former.


Okay.  By now I think we've established that it -is- my bad attitude
acting up.  Nevertheless, when I hear someone talking about preventing
data-driven attacks or building the ideal, genuine proxy...I'm forced
to think that the energy could probably be better expended elsewhere[6].








- -Steve

- -----
0       Or whatever it is that security types as a group do with their
        spare cycles.
1       Gross Conceptual Errors.
2       Either in terms of being unable to recover data or being unable
        to verify recovered data (i.e., loss of data or loss of trust).
3       Queued incoming or outgoing.  On a mail server, this could
        mean losing individual messages queued on the MTA.  On a web
        server (for example), this could be incoming requests for content.
4       I.e., 0% `secure' in this context doesn't mean 100% chance of
        being compromised.  Likewise, being 100% `secure' doesn't mean
        there is no chance of being compromised.
5       Barring certain edge conditions...i.e., the loonies that still
        have IIS servers vulnerable to nimda (for example).
6       Final disclaimer:  I'm really just grousing about matters of
        practical, day-to-day security administration.  I'm all for
        research and new technologies.  I myself write tinkerware,
        and have been known to dabble in airy, ephemeral theory.
        
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.3 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8AuDLG3kIaxeRZl8RAh30AJ4jki7KvHYT75mkDSI9AbVZGuq9hQCfTit6
Ee0xExRzA6XmWu8zUApXhOw=
=mVxh
-----END PGP SIGNATURE-----
_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr com
http://list.nfr.com/mailman/listinfo/firewall-wizards