On Thu, 20 May 1999 [EMAIL PROTECTED] wrote:
> All,
>
> >Reverse-proxy situations are not good architectures because they
> >essentially allow users to connect directly to internal hosts.
>
> This statement depends on your definition of "essentially". From a strict
> technical sense, there is not a direct IP or TCP-level connection. And as
> far as application-level data goes, user requests can be sanitized before
> being passed on to the back-end webservers (for example, you could strip
> out PUT commands, pipe characters and other junk). Of course, your
> webservers still might be susceptible to CGI attacks...
buffer overruns, evil CGIs, silly administrators, etc.
> True, but a proper reverse-proxy architecture should have some security at
> the back-end as well. Bolt down your webservers as if they WERE on the DMZ.
> 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.
> Of course, webservers can't live in a vacuum; content will need to be
> changed, or perhaps your webserver uses CORBA to talk to a back-back-end
> database. You can usually minimize such risks with strong authentication,
> more ACLs, IIOP and some other acronyms.
Most of which can be used to pass only the absolutely necessary traffic
to the Web server, and not HTTP (one good read of the HTTP specification
should make anyone cringe.) Too much can be passed in a valid URL to
expect putting publicly accessable servers on an internal network to be
anything other than an exception for most sorts of businesses that have a
need for internal network security. If you can lock it down enough to
give a resonable level of assurance, the server isn't doing enough to
warrant sitting on the internal network, and an order more security can
be gained from allowing it to talk only to an external host taking the
appropriate public traffic.
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.]
