different protocols thru double firewall

My client develops software in-house, and is using a double-firewall where
internet browsers talk to webserver 1 on port 80, which forwards the http
request to webserver 2 on a different port via a firewall. Webserver 2
contains the application logic (webserver 1 is essentially just a proxy).
Webserver 2 may talk to application servers on the "LAN" through another
firewall.

Both these web servers are in DMZ and not part of a domain.

There is a perception that it is less secure for webserver 2 to communicate
with an application server on the LAN via HTTP (e.g. a web service), as
opposed to a different protocol from the one that the original request comes
in from the browser.

Is there any justification for this concern, or is this just "security by
obscurity"?
There is a tendency to prefer e.g. .NET remoting between the web server and
the app server instead of a web service - and I would to hear some opinions
if that preference is justified.

SPidgornyMVP
Wed Nov 10 16:49:15 CST 2004

Architecting perimeter infrastructure is largely a matter of perception, so
there is no ultimate answer. In my opinion, the proposed protocol change in
the application zone gives little security benefit:

* If the public-facing server is compromised and owned by the intruder, she
will have access to the application server
* If the public-facing server does more than basic SSL reverse proxy, the
intruder will potentially be able to intercept sensitive information
including credentials sent to the application server regardless of the
protocol used (by modifying the code of the login web page, for example).
From that perspective, the public-facing server must be absolutely protected
and requires much quicker exposure response and thorough security review
* If the perimeter server is basic reverse proxy, that's pretty much the
same as exposing your ap server directly
* If your system management procedures (incl. security configuration,
intrusion detection and access control) will allow for a situation when an
intruder breaks through two layers of security, you have a bigger problem
than perimeter design.

The only thing you want to avoid is running the same application talking the
same protocol at each layer. The reason is obvious: if it's possible to fully
compromise a server with a certain exploit, the same exploit will be used to
penetrate further into your infrastructure. However, you must make a decision
about certain set of trusted infrastructure components. In the end, it's cost
vs. risk vs. functionality trade-off: I know many single-server
infrastructures that are secure because they're well-managed.

Sorry for the vague answer, but as I said there is no single answer.

Regards

S.





"richlm" wrote:

> My client develops software in-house, and is using a double-firewall where
> internet browsers talk to webserver 1 on port 80, which forwards the http
> request to webserver 2 on a different port via a firewall. Webserver 2
> contains the application logic (webserver 1 is essentially just a proxy).
> Webserver 2 may talk to application servers on the "LAN" through another
> firewall.
>
> Both these web servers are in DMZ and not part of a domain.
>
> There is a perception that it is less secure for webserver 2 to communicate
> with an application server on the LAN via HTTP (e.g. a web service), as
> opposed to a different protocol from the one that the original request comes
> in from the browser.
>
> Is there any justification for this concern, or is this just "security by
> obscurity"?
> There is a tendency to prefer e.g. .NET remoting between the web server and
> the app server instead of a web service - and I would to hear some opinions
> if that preference is justified.
>
>
>