1998-12-22-17:17:19 David Gillett:
> He's about given up on ISPs to provide protection, and is looking to set up
> his own server and protect it.

That's the only way to go. A public server of any sort -- but particularly a
web server, since that's such a rich service --- as to be very tightly
secured.

>   I keep seeing recommendations that HTTP servers should be in the 
> DMZ, but I'm not clear on WHY.  Is this, perhaps, to protect the 
> machines on the internal net from a compromised HTTP server?  In this 
> case, there wouldn't *be* any "rest" to protect.


The DMZ is still a partly-protected net, but a server _has_ to be exposed to
requests from the internet, from untrusted users, since they're the intended
customers of the server. So the usual firewall strategy can't do much to
protect it.

>   My inclination is to suggest a proxy machine as firewall, supplied 
> with content from the "real" server behind it.  But maybe there's a 
> flaw to this that I haven't quite grasped?

Depends on your design constraints. If you restrict your web server design to
running a poorly-supported OS with a bad track record of low-level IP stack
bugs, then a proxy firewall in the way is a good idea, to shield the
vulernable tender bits of the server's IP stack from low-level jiggery pokery
from outside attackers. If on the other hand you can run a well-supported OS
with good security for your web server, then all it needs is a screening
router, configured to prevent any _other_ protocols from reaching it.

The remainder of the securing comes in examining the server configuration, and
that requires an expert. The server software itself is usually relatively easy
to configure securely, particularly if it's a well-supported server (i.e.
Apache). The hard part is usually auditing all the CGIs, serverlets, ODBC
services, and other such bits of of clever goo. I like to split my public
servers across multiple machines that don't much trust each other, stick all
the static content on one and the clever bits on the other, to at least help
limit the damage.

After you've taken care of your OS security one way or another, taken care of
the http daemon's secureiry, and fixed any holes in your CGIs and whatnots,
then you've got the configuration management problem. The OS of any server
exposed to the internet (i.e. not protected by a proxy firewall) needs to be
kept up-to-date, and the http daemon needs to be kept up-to-date, and the
clever bits need periodic review to make sure they haven't been changed
inappropriately, and occasional re-evaluation to make sure they really are
securely written.

-Bennett
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]

Reply via email to