On Fri, 21 May 1999 [EMAIL PROTECTED] wrote:
> Paul, my old reverse-proxy friend :-)
>
> >> Put them on their own isolated network, and use router ACLs to permit
> >> inbound connections from the reverse proxy. Permit outbound traffic only
> to
> >> the reverse proxy, and deny everything else.
>
> >Then why put them on the internal network? If they're to be isolated,
> >then do it outside where public traffic belongs.
>
> Internal, but protected as if it were a DMZ. Security in layers is the way
> to go.
Assuming that your model is traditional enough to contain your most
protected assets on the internal network, it's still my opinion that the
machines taking the greatest ammount of risk should be not a part of that
infrastructure.
> IMHO, an isolated DMZ webserver placement is fine if all you want is a
> "Hello, World" website. But if you want to have a website that actually
> *does* something useful, a website like Amazon.com or Fidelity.com, you
> will inevitably need back-end connections to databases, or perhaps spawn
> extranet connections to partners, vendors, suppliers, etc. At some point,
> the rubber has to hit the road, you're going to have to let *something*
> through to the internal network.
I agree, I'm just saying that HTTP really isn't the best *something* to
let through. Why? Because the protocol specification is way too broad
to hope to bound the protocol to any measure of "safer." If you get it
so bounded, it'll be a roadblock to the usefulness of the site. Also,
CGI and its variants are very dangerous, and very exploitable. I'd
rather have my Web server exploited than my internal network. Database
queries can be bounded to "safer" normalization without a great deal of
work. Data limitation for inbound databases is a much easier egg to
crack than for HTTP to a Web server that's reacting to business need at a
high rate of change.
> (And personally, I hate using the term "internal" to describe everything
> behind the firewall. Most modern networks have grown too large and too
> complex for any part of it to be classified as strictly "external" or
> strictly "internal". The world isn't black-and-white, and neither is your
> network; there can always be shades of gray.)
Use "More protected", or whatever you're comfortable with. The
principles are still the same.
> As the number of webserver back-end connections and dependencies grow, so
> does the complexity of your perimeter architecture and firewall rules. At
Only for the case that they have to transit the boundary. That's why
looking at what transits the boundary is important. I've yet to see a
network database protocol that's as messy and open as HTTP. YMMV.
> that point, the "traditional" external-DMZ-internal architecture, IMHO,
> becomes unsatisfactory. I would rather pull all of the dirty work to a
> separate, hardened "internal DMZ" if you will, and just punch the HTTP
> through to a reverse proxy.
Then you're happy to give your assurance to Web server programmers,
Webmasters, Web designers, browser programmers and a bunch of folks whos
thrust and traditions haven't generally been security-aware. I'd rather
deal with DBAs and database protocols because there's a legacy of
structure, access control, and predictability. There's also much less
flex to the protocols involved. That means less potiential
exploitability. As with all general statements, implemetation variances
exist.
The HTTP protocol doesn't seem to enforce very many absolutes in most of
itself, including length and content of URIs and header fields. The
value to a reverse proxy versus just allowing the HTTP traffic in to the
server seems to be pretty low to me if you're talking about exploitation
attacks. All you're gaining is potentially some measure of transport
layer protection (which is a good thing, but you should be using a
reliable transport layer on your Web servers anyway.)
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
[EMAIL PROTECTED] which may have no basis whatsoever in fact."
PSB#9280
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
