On Fri, 21 May 1999 [EMAIL PROTECTED] wrote:
> Date: Fri, 21 May 1999 09:34:36 -0400
> From: [EMAIL PROTECTED]
> To: "Paul D. Robertson" <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Subject: Re: Re: Reverse proxy
>
> 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.
>
One's internal LAN != an internal DMZ. He was referring to an internal
LAN when he said "internal network". An "internal DMZ" would accomplish
the task of containing attackers in the event that a server there was
compromised whereas an internal LAN does not. This is not what he was
referring to.
>
> As the number of webserver back-end connections and dependencies grow, so
> does the complexity of your perimeter architecture and firewall rules. At
> 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.
But since the reverse web proxy does nothing for security, you garner no
extra security by putting the server on an "internal DMZ" over sticking
it in your tier 1 DMZ. I don't disagree that a two-tiered DMZ architecture
is a good thing for certain architectures (e.g. webserver in a tier 1
DMZ talking to backend databases in a tier 2 DMZ rather than the backend
databases on ones internal LAN). Just be sure that the "internal DMZ"
isn't your internal LAN and don't be lulled into thinking that a reverse
web proxy in your tier 1 DMZ proxying to the backend webserver in the
tier 2 DMZ buys you any security over just putting the webserver into the
tier 1 DMZ. If someone wants to fill me in on information to the contrary,
I'd be interested in discussing it.
>
> Regards,
>
> Christopher Zarcone
> Network Security Consultant
> RPM Consulting, Inc.
> #include <std.disclaimer.h>
>
>
> -
> [To unsubscribe, send mail to [EMAIL PROTECTED] with
> "unsubscribe firewalls" in the body of the message.]
>
AT&T Wireless Services
IT Security
UNIX Security Operations Specialist
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
